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REAL PARTY IN INTEREST : 

The real party in interest is the assignee of the present application, Siemens 
Aktiengesellschaft, a German corporation. 
RELATED APPEALS AND INTERFERENCES: 

There are no related appeals and no related interferences. 
STATUS OF CLAIMS: 

Claims 1-22 are the subject of the present appeal, and constitute all pending 
claims of the application. No claims were added or cancelled during prosecution 
before the Examiner. 
STATUS OF AMENDMENTS: 

The present appeal is being taken from the Office Action dated January 31, 
2007, which was not a Final Rejection, but which was the second time the claims on 
appeal have been rejected. In that Office Action, claim 1 was objected to because 
the Examiner stated the term "said examination images" in line 5 lacked sufficient 
antecedent basis. Amendment "D" was filed simultaneously with the present Notice 
of Appeal and Appeal Brief, wherein claim 1 was amended to overcome this 
objection. Amendment "D" has been entered and overcomes this rejection. 
SUMMARY OF CLAIMED SUBJECT MATTER: 

Claim 1 (the only independent claim of the application) is set forth below, with 
exemplary citations to the specification and drawings (Exhibit J) for the claim 
elements. 

1 . A medical system architecture comprising: 

an imaging modality for acquiring medical examination images of an 
examination subject (any of CT unit 1, MR unit 2, DSA unit 3, x-ray unit 
4, Fig. 1,p.5, 1.3-8); 
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a workstation selected from the group of workstations consisting of 
workstations for acquiring said examination images (any of 
workstations 5-8; Fig. 1, p. 5, 1.8-11), workstations for sending said 
examination image (also any of workstations 5-8) p. 5, 1.12-17), and 
workstations for receiving said examination images (viewing 
workstations 11; Fig. 1, p. 5, 1.18-24); 
a system connected to said workstation for transmitting said medical 
examination images to at least one location remote from said 
workstation (communication network 9; Fig. 1, p. 5, 1.12-14); and 
a call system allocated to said workstation for transmitting messages together 
with data representing said medical examination images to a remote 
location (Fig. 2, p.6, 1.17-23 and Fig. 3, p. 7, 1.3 -10). 
GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL: 
The following issues are presented in the present Appeal: 
Whether the subject matter of claims 1-14 is anticipated under 35 U.S.C. 
§1 02(e) by United States Patent No. 6,321,113 (Parker et al. Exhibit D); 

Whether the subject matter of claim 15 would have been obvious to a person 
of ordinary skill in the field of medical system architecture design under the 
provisions of 35 U.S.C. §103(a based on the teachings of Parker et al. in view of 
United States Patent No. 6,629,131 (Choi, Exhibit E); 

Whether the subject matter of claims 16-19 and 22 would have been obvious 
to a person of ordinary skill in the field of medical system architecture design under 
the provisions of 35 U.S.C. §1 03(a) based on the teachings of Parker et al., further in 
view of "Official Notice" of various types of communication software and 
components; 
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Whether the subject matter of claim 20 would have been obvious to a person 
of ordinary skill in the field of medical system architecture design under the 
provisions of 35 U.S.C. §1 03(a) based on the teachings of Parker et a!., further in 
view of United States Patent No. 6,304,898 (Shiigi, Exhibit G); and 

Whether the subject matter of claim 21 would have been obvious to a person 
of ordinary skill in the field of medical system architecture design under the 
provisions of 35 U.S.C. §1 03(a) based on the teachings of Parker et al., further in 
view of United States Patent No. 6,829,478 (Layton et al., Exhibit H). 
ARGUMENT : 

Rejection of Claims 1-14 Under 35 U.S.C. §102(e) as being Anticipated by 
Parker et aL 

The claims on appeal concern a medical system architecture of the type 
initially described wherein call system linked into the medical workflow for the 
transmission of messages, for example as datafiles, is allocated to at least one of the 
workstations. The user of a medical workstation, for example a modality, can send 
digital messages to an expert in an electronic manner proceeding from the console 
of the workstation. The medical modalities can be, for example, an MR, CT, 
ultrasound, X-ray or angiography device, a nuclear camera, supervision monitor, 
diagnostic workstation or irradiation apparatus. An automated expert call system to 
a mobile communication device proceeding from a workstation is thus obtained that 
is integrated into the work and data context of the medical workstation. Due to the 
combination of the workstation with a call system, a completely new application 
scenario arises wherein the radiologist — as an expert — is available by retrieval. 
This application scenario has not been realizable with the previous means (for 
example, image transfer to workstations). 
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Claim 1 claims a medical system architecture wherein examination images of 
an examination subject are acquired with an imaging modality, and are supplied to a 
workstation that is connected to a system for transmitting the examination images to 
at least one location that is remote from the workstation. The medical system 
architecture of claim 1 also requires a call system allocated to the workstation for 
transmitting messages together with data representing the medical images to a 
remote location. 

Appellant's position with regard to all rejections based on the Parker et al. 
reference (Exhibit D) is that there is no disclosure in the Parker et al. reference 
describing the generation or transmission of images in general, nor any disclosure of 
the transmission of medical images or examination images (both terms being used in 
claim 1, as noted above). The Parker et aL reference is exclusively concerned with 
the generation and transmission of text data, possibly combined with a 
representation of an electrical signal, such as an ECG. Appellants argued that an 
ECG is simply a trace or a curve, representing a single electrical signal, and does 
not represent a medical examination image, as that term is commonly understood by 
those of ordinary skill in the field of medical imaging. 

Numerous standard texts and dictionaries support the position of the 
Appellants that the term "medical examination image" is not considered by those of 
ordinary skill in the field of medical imaging to encompass an ECG. 

Attached hereto as Exhibit "A" is an excerpt from the McGraw-IHill Dictionary 
of Scientific and Technical Terms, providing a definition of medical imaging as the 
production of visual representations of body parts, tissues or organs. This definition 
clearly does not encompass an ECG, and electrocardiography is not listed as being 
among the general categories of medical imaging provided in that definition. 



Exhibit "B" is an excerpt from a standard medical text {Foundations of Medical 
Imaging), and in the introduction, that provides an overview of all types of medical 
imaging that will treated in the text, a definition is provided in the third full paragraph 
at page 4, stating that modern or contemporary medical imaging is a two-part 
process: (1) the collection of data concerning the interaction of some form of 
radiation with tissue, and (2) the transformation of these data into an image (or a set 
of images) using specific mathematical methods and computational tools. Clearly an 
ECG is simply a measurement of an electrical signal, and does not involve the 
interaction of radiation with a subject. In this regard, it is no different than a curve 
representing a measurement of blood pressure, temperature, etc., and thus falls into 
the category of "sensing" rather than "imaging." An excerpt from another standard 
text (Principles of Medical Imaging') Is attached hereto as "Exhibit "C". In the 
Preface to that textbook, the various categories of medical imaging (imaging 
modalities) are listed, and clearly ECG is not included. 

Appellants respectfully submit that the exhibits hereto are highly 
representative of the meaning that those of ordinary skill in the field of medical 
imaging ascribe to the term "medical examination images," and they clearly 
demonstrate that those of ordinary skill do not ordinarily consider an ECG to fall 
within that definition. 

In the context of the anticipation rejection based on Parker et al., this is not 
simply a trivial or semantic distinction. The fact that the Parker et al. reference does 
not provide any disclosure whatsoever with regard to acquiring or transmitting 
medical examination images, as that term is commonly understood by those of 
ordinary skill in the field of medical imaging, is sufficient to overcome the anticipation 
rejection of claims 1-14 based on the Parker et al. reference, since the Parker et al. 
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reference does not disclose all of the elements of claim 1 as arranged and operating 
in that claim. Claims 2-14 add further structure to the novel combination of claim 1, 
and therefore are not anticipated by Parker et al. for the same reasons. 
Rejection of Claim 15 Under 35 U.S.C. S1 03(a) Based on Parker et al. and Choi. 

As to all of the rejections under 35 U.S.C. §1 03(a) wherein Parker et al. is 
relied upon as the primary reference, in combination with respective secondary 
references or "official notice," the distinction between a "medical examination image" 
and an EGG is relevant because, in order to substantiate a rejection under 35 U.S.C. 
§1 03(a) based on a modification of the Parker et al. reference, the Examiner must 
provide evidentiary support for the position that it would have been obvious to a 
person of ordinary skill in the field of medical imaging to make use of the teachings 
of Parker et al., which are exclusively directed to the generation and transmission of 
an ECG, for the purpose of generating and transmitting true "medical examination 
images." In view of the above evidence showing that those of ordinary skill in the 
field of medical imaging do not consider an ECG to fall into the category of a 
"medical examination image," Applicants respectfully submit the Examiner cannot 
simply conclude, without proper evidentiary support, that there is no difference 
between the two. Appellants respectfully submit the Examiner has not provided the 
proper evidentiary support required by numerous decisions of the United States 
Court of Appeals for the Federal Circuit indicating a motivation, inducement or 
guidance in any of the references of record to apply the teachings of Parker et a!., 
which are exclusively disclosed in that reference in the context of ECG generation 
and transmission, to the generation and transmission of "medical examination 
images." In view of the significant differences between an ECG and a true "medical 
examination image," Appellants respectfully submit that even if a person of ordinary 
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skill in the field of medical imaging had the insight to apply the ECG-based teachings 
of Parker et al. to the field of medical imaging, this would be an insight supporting 
patentability, rather than a basis for negating patentability. 

The Federal Circuit stated in In re Lee 227 F.3d 1338, 61 U.S.P.Q. 2d 1430 
(Fed. Cir. 2002) : 

"The factual inquiry whether to combine references must be thorough 
and searching. ...It must be based on objective evidence of record. 
This precedent has been reinforced in myriad decisions, and cannot be 
dispensed with." 

Similarly, quoting C.R Bard. Inc. v. M3 Systems, Inc. 157 F.3d 1340, 1352, 

48 U.S.P.Q. 2d 1225, 1232 (Fed. Cir. 1998) . the Federal Circuit in Brown & 

Williamson Tobacco Court v, Philip Morris, Inc., 229 F.3d 1120, 1124-1125, 56 

U.S.P.Q. 2d 1456, 1459 (Fed. Cir. 2000) stated: 

[A] showing of a suggestion, teaching or motivation to combine the 
prior art references is an 'essential component of an obviousness 
holding'. 

In In re Dembiczak, 175 F.3d 994,999, 50 U.S.P.Q. 2d 1614, 1617 (Fed. Cir. 

1999) the Federal Circuit stated: 

Our case law makes clear that the best defense against the subtle but 
powerful attraction of a hindsight-based obviousness analysis is 
rigorous application of the requirement for a showing of the teaching or 
motivation to combine prior art references. 

Consistently, in In re Rouffet 149 F.3d 1350, 1359. 47 U.S.P.Q. 2d 1453, 

1459 (Fed. Cir. 1998) . the Federal Circuit stated: 

[E]ven when the level of skill in the art is high, the Board must identify 
specifically the principle, known to one of ordinary skill in the art, that 
suggests the claimed combination. In other words, the Board must 
explain the reasons one of ordinary skill in the art would have been 
motivated to select the references and to combine them to render the 
claimed invention obvious. 

In Winner International Royalty Corp. v, Wang, 200 F.3d 1340, 1348-1349, 53 
U.S.P.Q. 2d 1580, 1586 (Fed. Cir. 2000) , the Federal Circuit stated: 
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Although a reference need not expressly teach that the disclosure 
contained therein should be combined with another, ... the showing of 
combinability, in whatever form, must nevertheless be clear and 
particular. 

Lastly, in Crown Operations International, Ltd. v. Solutia. Inc., 289 F.3d 1367, 

1376. 62 U.S.P.Q. 2d 1917 (Fed. Cir. 2002) , the Federal Circuit stated: 

There must be a teaching or suggestion within the prior art, within the 
nature of the problem to be solved, or within the general knowledge of 
a person of ordinary skill in the field of the invention, to look to 
particular sources, to select particular elements, and to combine them 
as combined by the inventor. 

For these reasons, even if the Examiner's statements regarding the individual 
teachings of the Choi reference (Exhibit "E") are accurate, Appellants respectfully 
submit the Examiner has not satisfied the aforementioned rigorous evidentiary 
standards for the Examiner's interpretation of the term "medical image" in claim 1, 
nor as to the alleged guidance, based on teachings in the references themselves, for 
combining the references in the manner proposed by the Examiner. 

Claim 15, therefore, would not have been obvious to a person of ordinary skill 
in the field of medical system architecture design under the provisions of 35 U.S.C. 
§1 03(a), based on the teachings of Parker et al. and Choi. 

Rejection of Claims 16-19 and 22 Under 35 U.S.C. §103(a) as being 
Unpatentable over Parker et al, in View of "Official Notice" 

With regard to claim 16, the Examiner took Office Notice that the concept and 
advantages of using Corba technology are well known, and the Examiner took the 
same position with regard to Official Notice with respect to the use of instant 
messaging technology in claim 17, Java Enterprise Beans technology in claim 18, 
the use of Java Applet in a browser with regard to claim 19 and the use of a beeper 
with regard to claim 22. For brief descriptions of Corba and Java Beans, the 
Examiner cited Microsoft Computer Dictionary, 5*^ Ed. (Exhibit "F). 
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For the same reasons discussed above in connection with the rejection based 

on Parker et al. and Choi, Appellants respectfully subnnit that even if the Examiner's 

conclusions regarding the various items for which Official Notice has been taken are 

correct, the references still do not provide the rigorous evidentiary support as to 

teachings that would guide a person of ordinary skill in the medical architecture 

technology to combine the known information with the subject matter of claim 1 . 

Rejection of Claim 20 under 35 U.S.C. §1 03(a) as Unpatentable over Parker et 
al- in view of Shiiqi 

The Examiner has relied on the Shiigi reference (Exhibit "G") as teaching a 

WAP phone, which the Examiner acknowledges is not taught in the Parker et al. 

reference. Appellants acknowledge that the Shiigi reference provides such a 

teaching, however, for the same reasons noted above with regard to the other 

rejections under 35 U.S.C. §1 03(a), Appellants respectfully submit the Examiner has 

failed to satisfy the high standard of evidence required to support the position that 

either of the Parker et al, or Shiigi references provides teachings, motivations, 

inducements or guidance to a person of ordinary skill in the field of medical system 

architecture design, so as to justify a conclusion that it would have been obvious to 

such a person of ordinary skill to modify the Parker et al. reference in accordance 

with the disclosure of the Shiigi reference. This is particularly true, as with the other 

rejections under 35 U.S.C. §1 03(a), in view of the discussion above regarding the 

term "medical image" in claim 1 and the lack of a teaching thereof in the Parker et al. 

reference. 

Rejection of Claim 21 under 35 U.S.C. §103(a) as Being Unpatentable over 
Parker et aL in view of Lavton et al. 

The Examiner relied on the Layton et al. reference (Exhibit "H") as teaching 

an SMS phone, which the Examiner acknowledged is not disclosed in the Parker et 
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al. reference. Appellants acknowledge that the Layton et al. reference provides such 
a teaching, but for the reasons noted above with regard to the other rejections under 
35 U.S.C. §1 03(a), Appellants respectfully submit the Examiner has failed to satisfy 
the high standard of evidence required to support the position that either of the 
Parker et al. or Layton et al. references provide teachings, motivations, inducements 
or guidance to a person of ordinary skill in the field of medical system architecture 
design, so as to justify a conclusion that it would have been obvious to a person of 
ordinary skill to modify the Parker et al. reference in accordance with the teachings 
of the Layton et al. reference. This is particularly true, as with the other rejections 
under 35 U.S.C. §1 03(a) in view of the discussion above regarding the term "medical 
image" in claim 1 and the lack of a teaching thereof in the Parker et al. reference. 
CONCLUSION: 

For the foregoing reasons, Appellants respectfully submit the Examiner is in 
error in law and in fact in rejecting claims 1-22 that are of the subject of the present 
Appeal. Reversal of those rejections is therefore proper, and the same is 
respectfully requested. 

The Appeal Brief filing fee was paid at the time the previous Appeal Brief was 

filed. 

The Commissioner is hereby authorized to charge any additional fees which 
may be required, or to credit any overpayment to account No. 501519. 

Submitted by/ 



bubmitted by/\ i ^ 



(Reg. 28.982) 



SCHIFF, HARDIN LLP, CUSTOMER NO. 26574 

Patent Department 
6600 Sears Tower 
233 South Wacker Drive 
Chicago, Illinois 60606 
Telephone: 312/258-5790 
Attorneys for Appellants. 
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CLAIMS APPENDIX 

1 . A medical system architecture comprising: 

an imaging modality for acquiring medical examination images of an 
examination subject; 

a workstation selected from the group of workstations consisting of 
workstations for acquiring said medical examination images, 
workstations for sending said medical examination images, and 
workstations for receiving said medical examination images; 

a system connected to said workstation for transmitting said medical 
examination images to at least one location remote from said 
workstation; and 

a call system allocated to said workstation for transmitting messages together 
with data representing said medical examination images to a remote 
location. 

2. A medical system architecture as claimed in claim 1 wherein said 
workstation also processes data associated with said examination images, and 
further comprising a memory connected to said system which stores said data and 
said examination images in allocated fashion. 

3. A medical system architecture as claimed in claim 1 wherein said call 
system allows manually modifiable entries of auxiliary information to ensue 
automatically from object types stored in a data bank. 

4. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a mobile 
communication device. 
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5. A medical system architecture as claimed in claim 4 wherein said user 
front end is integrated in an application at said workstation. 

6. A medical system architecture as claimed in claim 4 wherein said 
communication services comprises a communication server and a communication 
system. 

7. A medical system architecture as claimed in claim 1 wherein said call 
system allows a manually modifiable entry of a message recipient to ensue 
automatically in said message. 

8. A medical system architecture as claimed in claim 1 wherein said call 
system allows a manually modifiable entry of a current patient, being examined with 
said modality, to ensue automatically in said message. 

9. A medical system architecture as claimed in claim 1 wherein said call 
system allows a manually modifiable entry of a current procedure being executed by 
said modality to ensue automatically in said message. 

10. A medical system architecture as claimed in claim 1 wherein said call 
system allows entry of an arbitrary text as specific auxiliary information in said 
message. 

11. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a mobile communication device with a display. 
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12. A medical system architecture as claimed in claim 11 wherein said call 
system includes a voice input unit at said workstation allowing a voice input to be 
transmitted to said communication device as an audio data file, and wherein said 
communication device comprises an audio transducer allowing emission of said 
voice input at said communication device. 

13. A medical system architecture as claimed in claim 1 wherein said 
workstation has a monitor on which said medical examination images are displayed, 
and wherein said call system is connected to said workstation to cause a 
communication window to be overlaid on said examination images at said monitor 

14. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a mobile communication device with a display and an information 
return channel from said communication device to said workstation allowing 
information to be transmitted from said communication device to said workstation. 

15. A medical system architecture as claimed in claim 14 wherein said 
communication device transmits a confirmation of receipt of said message to said 
workstation after said message has been read at said communication device. 

16. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a mobile 
communication device, and wherein said workstation communicates with said 
communication service via Corba technology. 
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17. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a mobile 
communication device, and wherein said workstation communicates with said 
communication service via Instant Messaging technology. 

18. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a mobile 
communication device, and wherein said workstation communicates with said 
communication service via Java Enterprise Beans technology. 

19. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a mobile 
communication device, and wherein said user front end comprises a Java applet in a 
browser. 

20. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a WAP cell phone. 

21. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a SMS cell phone. 

22. A medical system architecture as claimed in claim 1 wherein said call 
system comprises a user front end, a communication service and a beeper with a 
display. 
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RELATED APPEALS AND INTERFERENCES 

None. 
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EVIDENCE APPENDIX 

Exhibit A: 



th 



McGraw-Hill Dictionary of Scientific and Technical Terms, 5 
Ed., Parker (Editor in Chief (1994)) - submitted with January 17, 
2006 Amendment that was entered upon the filing of the RCE 
on May 2, 2006. 

Exhibit B: "Foundations of Medical imaging," Cho et al. (1993) pages 3-5 - 

submitted with January 17, 2006 Amendment that was entered 

upon the filing of the RCE on May 2, 2006. 
Exhibit C: "Principles of Medical Imaging," Shung et al. (1992) pages xiii - 

xiv - submitted with January 17, 2006 Amendment that was 

entered upon the filing of the RCE on May 2, 2006. 
Exhibit D: United States Patent No. 6,321,113 (Parker et al.) - cited in the 

Final Rejection dated June 26, 2006. 
Exhibit E: United States Patent No. 6,629,131 (Choi) - cited in the Final 

Rejection dated June 26, 2006. 
Exhibit F: Microsoft Computer Dictionary, 5^*^ Ed. - cited in the Final 

Rejection dated June 26, 2006. 
Exhibit G: United States Patent No. 6,304,898 (Shiigi) - cited in the Final 

Rejection dated June 26, 2006. 
Exhibit H: United States Patent No. 6,829,478 (Layton et al.) - cited in the 

Final Rejection dated June 26, 2006. 
Exhibit I: Request for Continued Examination (RCE) Transmittal - filed 

May 2, 2006. 

Exhibit J: Figs. 1-3 - filed as part of the original application on November 
19, 2001. 
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meconium ileus 



■COPTEHA 




i mm 

n fly (Panorpa). 



in the fetal intestine, becoming the first fecal discharge of the 
newborn. I ms'ko-ne-sm | 

meconium ileus [med] Intestinal obstiuction in the newborn 
with cystic fibrosis due to trypsin deficiency. ( ma'ko-ne-am 
'il'C'ds ) 

Mecoptera [inv zoo] The scorpion flies, a small order of 
insects; adults are distinguished by the peculiar prolongation of 
the head into a beak, which bears chewing mouthparts. 

I me'kajrtOT^ } . . u -^w • 

mecystasis [physio] Increase in muscle length with main- 
tenance of the original degree of tension. { me'sis-ta-sas ) 

media [histol] The middle, muscular layer in the wall of a 
vein, artery, or lymph vessel. { 'me-dg-3 } 

media conversion [comput sci] The transfer of data from 
one storage type (such as punched cards) to another storage type 
(such as magnetic tape). { 'me^g-s kan.varzhOT } 

media conversion butler [comput sci] Large storage area, 
such as a drum, on which data may be stored at low speed during 
nonexecution time, to be later transferred at high speed into core 
memory during execution lime. ( 'me-de-s k^n.v^rzhdn .bsf* 
sr ) 

medlad [ anat] Toward the median line or plane of the body 
or of a part of the body. ( 'me-de.ad } 

medial [aNat] 1 . Being internal as opposed to external (lat- 
eral). 2. Toward the midline of the body, [sci tech] Located 
in the middle. ( 'me-de-al ) 

medial arteriosclerosis [med] Calcification of the tumca 
media of small and medium-sized muscular arteries. Also 
known as medial calcinosis; Monckeberg's arteriosclerosis. 
I 'me*de-3l ,artire-6-skl3'ro*s3s | 

medial calcinosis See medial arteriosclerosis. { 'me-de*©! ,kal- 
S3'nd-S9s } 

medial lemniscus [anat] A lemniscus arising in the nucleus 
gracilis and nucleus cuneatus of the brain, crossing immediately 
as internal arcuate fibers, and terminating in the posterolateral 
ventral nucleus of the thalamus. { 'me-de-sl lem'nis'kos ) 

medial moraine [geol] 1 . An elongate moraine carried in or 
upon the middle of a glacier and parallel to its sides. 2. A 
moraine formed by glacial abrasion of a rocky protuberance 
near the middle of a glacier. { 'me-de-sl ms'ran } 

medial necrosis [med] Death of cells in the tunica media of 
ancries. Also known as medionecrosis. [ 'me*d€'3l ne'kro* 

m^ia migration [chem eng] Carryover of fibers or other 
filter material by liquid effluent from a filter uniL I 'me*de*3 

mT'gra-shwi ) ^. ^ . - _ 

median [math] 1. Any line m a mangle which joins a vertex 
10 the midpoint of the opposite side. 2. The line that joins the 
midpoints of the nonparallel sides of a trapezoid. Also known 
as midline, [sci tech] Located in the middle, [stat] An 
average of a series of quantities or values; specifically, the quan- 
tity or value of that item which is so positioned in the series, 
when arranged in order of numerical quantity or value, that there 
are an equal number of items of greater magnitude and lesser 
magnitude. ( 'me-de-an I r„ . , - ^- u 

median effective dose See effective dose 50. ( 'me-de-^n i fek- 

tiv 'dos ] 

median infective dose See infective dose 50. { 'me-de-sn 
in'fekniv 'des ) 

median lethal dose See lethal dose 50. i 'me-de-OT leth-sl 

m^^ian lethal lime [microbio] The period of time required 
for 50% of a large group of organisms to die following a specific 
dose of an injurious agent, such as a drug or radiation. ( 'me- 
de-3n 'Icth-al ,tim i 

median mass [oeol] A less disturbed structural block m the 
middle of an erogenic belt, bordered on both sides by erogenic 
structure, thrust away from it. Also known as betwixt moun- 
tains; Zwischengebirge. { 'me-de-an 'mas } 

median maxillary cyst [med] Cystic dilation of embryonal 
inclusions in the incisive fossa or between the roots of the central 
incisors. Also known as nasopalatine cyst. | 'me-de-^n 'mak* 

ss.lere ,sist ) _ . ^ , r 

median nasal process [embryo] The region below the fron- 
tonasal sulcus between the olfactory sacs; forms the bridge and 
mobile septum of the nose and various parts of the upper jaw 
and lip. i 'me-de-sn "naz^al ,pra-s3s ) 

median nerve test [med] A test for loss of function of the 
median nerve by having the patient abduct the thumb at right 



medicinal oltW i 

angles to the palm with fingertips in contact and forming 
pyramid. | 'me-de-an 'narv .test | 

median particle diameter [geol] The middlemost pai^c^^^M 
diameter of a lock or sediment, larger than 50% of the diaiM|^^5| 
in the distribution and smaller than the other 50%. { 'm6*de^|; j 
an 'pard-3-k3l di,am-^-or ) ; | 

median point [math] The point at which all three nicdian^p| 
of a triangle intersect. | 'med-e-an ,p6int. ) S^ >^ 

median strip [civ eng] A paved or planted section dividing^}| 
a highway into lanes according to direction of travel. { 'ind*^S|| 
de-sn 'strip } , | 

medlastinltis [med] Inflammation of the mediastimimi^| 
{ ,me-de,ast3'riid-3s } '^g/j 

mediastinum [anat] 1. A partiticm separating adjacent paits^ j:j. ; 
2. The space in the middle of the chest between the two pleurae, i 
i .mc-de-s'slrnam } . f :ts 

medical bacteriology [med] A branch of medical microbi- 1; | 
ology that deals with the study of bacteria which affect human^^^i 
health, especially those which produce disease. [ 'med*»*k3l | 
bak,tire'fil-»jc | . &f 

medical chemical engineering [chem eng] The application ^ f 
of chemical engineering to medicine, frequently involving mass 
transport and separation processes, especially at the molecular;^ 
level. ( *med-a'k3l 'kem-a-kDl .cn'jo'niri?) ) 

medical climatology [med] The study of the relation be- S| 
tween climate and disease. { 'med-s*3l .kirmo'tfil-sje } ,^-^| 

medical electronics [electr] A branch of electronics in ;Q 
which electronic instruments and equipmem are used for such 
medical applications as diagnosis, therapy, research, anesthesia O 
control, cardiac control, and surgery. I 'med'3*k3l i.lck'trSn; 

iks 1 ^ ■ - ^ 

medical entomology [med] The study of irisects thai arc ; v| 

vectors for diseases and parasitic infestations in humans and r | 

domestic animals. ( 'med*9*kal ,cn-is'mfil*3*je ) S\ 
medical ethics [med] Principles and moral values of prcrper | 

medical conduct. { 'med-s-ksl *eth-iks | : | 

medical examiner [med] A professionally qualified physi- 1 

cian duly authorized and charged by a governmental unit to , i 

determine facts concerning causes of death, particularly deaths | 

not occurring under natural circumstances, and to testify thereto 

in courts of law. { 'med-p-k©l ig'zam-^-nor ) 
medical frequency bends [commun] A collection of radio 

frequency bands allocated to medical equipment in the United 

States. I 'med-a-k^l 'fre-kwsn-se .banz ] 
medical genetics [oen] A field of human genetics concerned 

with the relationship between heredity and disease. [ 'med*?' 

ksl j^'ned'iks ) 

medical geography [med] The study of the relation between: 
geographic factors and disease. ( 'med*s-k9l je'Sg^^^ ] 

medical history [med] An account of a patient's past^aiid 
present state of health obtained from the patient or relatives. 
I 'med-3-k3l 'his-tre 1 

medical imaging [med] The production of visual rcpresen' 
tations of body parts, tissues, or organs, for use in clinical 
diagnosis; encompasses x-ray methods, magnetic resonance 
imaging, single -photon -emission and positron-emission 
tomography, and ultrasound. ( 'mcd-d-ksl 'im-ijnrj } 

medical microbiology [med] The study of microorganisms 
which affect human health. { 'med-a-k^l ImT'kro-bT'fil-a-je ] 

medical mycology [med] A branch of medical microbiolog) 
that deals with fungi that are pathogenic to humans. [ *med^ 
ksl mT'kal-9-je } - - v- 

medical parasitology [med] A branch of medical microbi- 
ology which deals with the relationship between humans and y : 
those animals which live in or on them. { 'med-s-kal .paro- 
si'tal'S-je } . 

medical protozoology [med] A branch of medical micro- 
biology that deals with the study of Protozoa which are parasites 
of humans. { 'med-a-kal ,pro-d6-z6'fil-3-je | 

medical radiography [med] The use of x-rays to produce 
photographic images for visualizing internal anatomy as an aid 
in diagnosis. | 'med-3-kal ,rad-c-'agTa-fe 1 

medication [med] 1. A medicinal substance. 2. Treatmcni 
by or administration of a medicine. { .med-o'ka-shan ] 

medicinal [med] Of, pertaining to, or having the nature ol 
medicine. { ms'dis-an-al | 

medicinal oil [mater] A highly refined, colorless, tasteless 
and odorless petroleum oil used medicinally as an internal lu 
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INTRODUCTION 



The study of medical imaging is concerned with the interaction of all forms of 
r.uliation with tissue and the development of appropriate technology to 
i xlract clinically useful information from observations of this interaction. 
Such information is usually displayed in an image format. Medical images can 
be as simple as a projection or shadow image — as first produced by Rontgen 
nearly 100 years ago and utilized today as a simple chest X-ray — or as 
complicated as a computer reconstructed image — as produced by computer- 
t/cd tomography (CT) using X-rays or by magnetic resonance imaging (MRI) 
using intense magnetic fields. 

Although, strictly speaking, medical imaging began in 1895 with Rontgen's 
discoveries of X-rays and of the abihty of X-rays to visualize bones and other 
Niructures within the living body [1], contemporary medical imaging began in 
I lie 1970s with the advent of computerized tomography [2, 3]. Early, or what 
we call classical, medical imaging utilizes images that are a direct manifesta- 
tion of the interaction of some form of radiation with tissue. Three examples 
will illustrate what we mean by classical imaging. First is the conventional 
\.ray procedure in which a beam of X-rays is directed through the patient 
.uito a film. The developed film provides a shadow image of the patient which 
IS a direct representation of the passage of X-rays through the body. Al- 
» hough such images are not quantitative, they do provide some measure of 
I he attenuation of X-rays in tissue. Thus a section of soft tissue will appear 
.i.irker than an equally thick section of bone, which attenuates more of the 
X-rays. It should be noted that even with current technological developments 
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4 INTRODUCTION 

conventional X-ray imaging stUI represents the major imaging procedure at 
most medical facilities. 

As a second example of classical imaging, consider a conventional nuclear 
medicine procedure. Here a radioactive material is injected into the patient 
and its course followed by a detector which is moved over the patient in a 
specified manner. Although the image recorded by the detector generally has 
poor spatial resolution, its real advantage is that it provides a measure of 
physiological function from the time course of the radioisotope uptake. 
Qearly the conventional nuclear medicine image is a direct measure of the 
location and concentration of the radioactive isotope used. 

As a final example of classical imaging, consider conventional medical 
ultrasound. Here, a pulse of ultrasonic energy is propagated into the patient 
and the backscattered echo signal is recorded by the same transducer. By 
angulating or moving the transducer (or by using a transducer array) position- 
ally sequential echo signals are recorded, and a cross-sectional image of the 
subject is displayed directly on a video monitor. Ultrasound images are really 
a mapping of echo intensities and are a direct result of the interaction of the 
ultrasound pulse with tissue. 

In this text we will define modem or contemporary medical imaging 
operationally as a two-part process; (1) the collection of data concerning the 
interaction of some form of radiation with tissue, and (2) the transformation 
of these data into an image (or a set of images) using specific mathematical 
methods and computational tools. Note that our definitions for both classical 
and modem imaging are consistent with our general definition of medical 
imaging, given in the first paragraph of this chapter. Note also that modem 
imaging' can be represented as a generalization of classical imaging and that 
classical imaging is simply a special case of modem imaging in which the 
image forms directly from the interaction process. Whereas classical imaging 
is direct and intuitive, modern imaging is indirect and, in many cases, counter 
intuitive. Since modem images are formed by processing, reformulating, or 
reconstructing an image from the tissue/radiation interaction data base, the 
process is often referred to as "reconstmction" and the image as a "recon- 
stmcted image." 

The first device capable of producing true reconstructed images was 
developed by G. N. Hounsfield [2] in 1972 at EMI in England. Hounsfield^s 
X-ray computerized tomograph device was based in part on mathematical 
methods developed by A. M. Cormack [4] a decade earlier. For their efforts 
Hounsfield and Cormack were awarded the Nobel Prize in medicine in 1979. 
Put quite simply, CT imaging is based on the mathematical formalism that 
states that if an object is viewed from a number of different angles, then a 
cross-sectional fanage of it can be computed (or "reconstructed"). Thus X-ray 
CT yields an image that is essentially a mapping of X-ray attenuation or 
tissue density. 

The introduction of X-ray CT in 1972 represents the real beginnmg of 
modern imaging and has altered forever our concept of imaging as merely 



Table 1-1 'Vd 



2-D and 3-E 

Projection 

Reconstruct 



Iterative 
Method 



Fourier 
Reconstruct! 



t?*king a picture, Ii 
^^j)^iking quantitativ 
icvnu)graphy to con^ 
JTicfU of two new 
timiagraphy (SPEC 
IfjtH^li^iitions to tin 
■ ti^MR) has led to 
jgirtrently being e 
^lilipcdahce tomogn 
inherent to the de^ 
dt^vclopment of n 

"r^bic i-i. 

in this chapter ^ 
v>>tkHis medical im£ 
*¥^vlvniques are shovf 
iiHci rogation wavel 
i^c^ding chapters vs 
imiiging modalities, 
^ify, be treated sep; 
jtcJld of medical ima 



I f THE BEGINN 

! history of med 
vViihclm Konrad R< 



cedure at 

il nuclear 
le patient 
tient in a 
erally has 
easure of 
t uptake, 
ire of the 

1 medical 
le patient 
ducer. By 
) position- 
ige of the 
are really 
ion of the 

1 imaging 
iming the 
formation 
:hematical 
h classical 
)f medical 
at modem 
g and that 
which the 
al imaging 
;j5, counter 
ulating, or 
\ base, the 
a "recon- 

nages was 
ounsfield's 
thematical 
leir efforts 
le in 1979. 
lalism that 
les, then a 
rhus X-ray 
nuation or 

ginning of 
as merely 



THE BEGINNING WITH X-RAYS 5 



Table 1-1 3-D image reconstruction algorithms 





2-D Projection 
Reconstruction 


Parallel-Beam Mode 


2-D and 3-D 

Projection 

Reconstruction 


Fan-Beam Mode 


3-D Projection 
Reconstruction 


ParalleJ-Beam Mode 






' Cone-Beam Mode 


Iterative 


Algebraic Reconstruction Technique (ART) 


Method 


Maximum Likelihood Reconstruction (MLR) or 
Expectation Maximization (EM) Reconstruction 


Fourier 


Direct Fourier Reconstruction (DFR) 


Reconstruction 


Direct Fourier Imaging (DFl) in NMR 



i;»king a picture. It has also led to the development of 3-D imaging and is 
nKiking quantitative imaging a reality. The application of reconstructive 
ii)mography to conventional nuclear medicine imaging has led to the develop- 
ment of two new imaging modahties: single photon emission computed 
ifiinography (SPECT) and positron emission tomography (PET), Similar 
;ipplications to the laboratory technique of nuclear magnetic resonance 
rNMR) has led to magnetic resonance imaging (MRI). The CT concept is 
currently being extended to 3-D magnetoencephalography, electrical 
impedance tomography, and photon migration tomography, to name a few. 
Inherent to the development of these new imaging modalities has been the 
development of new reconstruction techniques, which are detailed in 
I iibJe 1-1. 

In this chapter we seek to provide a brief historical perspective for the 
vjirious medical imaging modalities that are currently important. The various 
K chniques are shown in Figs. 1-1 and 1-2 where they are characterized by the 
inierrogation wavelengths. A parallel sequence will be followed in the suc- 
iceding chapters which provide more detailed discussions of the various 
imaging modalities. Although the various imaging techniques will, of neces- 
sity, be treated separately, our goal is to provide a unified approach to the 
iicld of medical imaging. 



1-1 THE BEGINNING WITH X-RAYS 



'\ hc history of medical imaging really began on November 8, 1895, when 
Wilhelm Konrad Rontgen reported the discovery of what he called "a new 
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Preface 



The field of medical imaging is growing at a rapid pace. Since the early 1960s, 
three new imaging modalities, namely, radionuclide imaging, ultrasound, and 
magnetic resonance imaging, have appeared and matured. Along with X-ray they 
are among the most important clinical diagnostic tools in medicine today. Ra- 
dionuclide imaging, although its resolution cannot match that of other modalities, 
uses radioactive isotopes attached to biochemically active substances to yield 
unique information about the biochemical or physiological function of the organ 
which is unattainable otherwise. Ultrasound scanners use high frequency sound 
waves to interrogate the interior of the body. They are capable of depicting 
anatomical details with excellent resolution. Ultrasound is particulary suited to 
situations where exposure to ionizing radiation is undesirable, such as in obstetri- 
cal and neonatal scanning, and to imaging structures in motion, such as heart 
valves. Magnetic resonance imaging, however, has been envisioned to be the 
most exciting of them all by fer because it also uses a form of nonionizing radia- 
tion, can achieve superior resolution, and is capable of yielding physiological in- 
formation. In this period, significant progress has also been achieved in conven- 
tional X-ray radiography. Improved design or introduction of better materials in 
image intensifiers, intensifying and fluoroscopic screens, and photographic films 
has enhanced the resolution to a significant degree without adding higher patient 
radiation exposure levels. It is therefore plausible to understand why conventional 
radiography is still routinely used clinically for the diagnosis of many diseases and 
is the gold standard to which newer imaging modalities are compared. 

Unquestionably, the digital revolution is the primary reason that has caused 
the medical imaging field to experience the explosive growth that we are seeing 
today. Computer and digital technology along with advances in electronics have 
made data acquisition fest and mass data storage possible. These are the most es- 
sential ingredients for the practical realization of tomographicai reconstruction 
principles. X-ray computed tomography (CT), digital radiography, real-time ultra- 
sonic scanners, single-photon emission computed tomography <SPECT), positron 
emission tomography (PET), and magnetic resonance imaging (MRI), which 
came about after the early 1970s, are just a few well-known products of the digi- 
tal revolution in medical imaging. 

While the development of these new imaging approaches may have con- 
tributed greatly to the improvement of health care, it has also contributed to the 
rising cost of health care. A chest X-ray costs only $20-30 per procedure whereas 
a magnetic resonance scan may cost up to $1000, let alone the expenses associ- 
ated with acquiring and installing such a scanner. The cost-to-benefit ratio for 
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these expensive procedures in certain cases is sometimes not as clear as in others. 
Therefore it is not unusual that the clinical efficacy and contribution of these 
modalities to patient care are being scrutinized and debated constantly by the 
medical community as well as the public. 

This book is intended to be a university textbook for a senior or first-year 
graduate level course in medical imaging offered in a biomedical engineering, 
electrical engineering, medical physics^ or radiological sciences department. 
Much of the material is calculus based. However, an attempt has been made to 
minimize mathematical derivation and to place more emphasis on physical con- 
cepts. A major part of this book was derived from notes used by the authors to 
teach a graduate course in medical imaging at the Bioengineering Prpgram of 
Pennsylvania State University since the late 1970s. This book covers all four ma- 
jor medical imaging modalities, namely. X-ray including CT and digital radiogra- 
phy, ultrasound, radionuclide imaging including SPECT and PET, and magnetic 
resonance imaging. It is divided into four chapters in which a similar format is 
used. In each chapter fundamental physics involved in a modality is given first, 
followed by a discussion on instrumentation. Then various diagnostic prbcediu-es 
are described. Finally, recent developments and biological effects of each modal- 
ity are discussed. At the end of each chapter a list of relevant references, further 
reading materials, and a set of problems are given. The purpose of this textfxx^k 
is to give students with an adequate background in mathematics and physics an 
introduction to the field of diagnostic imaging; the materials discussed should be 
more than sufficient for one semester. However, the book may also be used as the 
text for a two-semester course in medical imaging when supplemented by addi- 
tional materials or by inclusion of more mathematic detail . 

Although this book has been written as a college textbook, radiologists with 
some technical background and practicing engineers or physicists working in 
imaging industries should also find it a valuable reference in the medical imaging 
field. As a final note, it should be pointed out that there are other imaging meth- 
ods that have been used in medicine [e.g., thermography, magnetic imaging, and 
microwave imaging (Hendee, 1991)], They are not included in this book primar- 
ily due to their limited utility at present. Readers who are interested in these 
modalities may refer to several books listed in the following reference section. 
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ABSTRACT 



A method and system for managing cardiac rescue events is 
disclosed. Unlike prior systems, this method and system 
us^ a rescue scene computer to obtain patient and incident 
data at the rescue scene and then marry that data with EGG 
rescue data and automated external defibrillator (AED) 
rescue data. All of this data is then simultaneously trans- 
mitted to a base computer at an emergency medical center 
for review. Accordingly, a reviewer at the base computer can 
immediately review the ECG and AED performance in 
context with patient and incident data. The method and 
system includes a WiiKlows-based single screen graphical 
user interface for entering and reviewing the data and 
particularly includes a window for viewing ECG data simul- 
taneously with entry and review of all other data available in 
the single screen user interface. The system and method 
comprises one or more of the following elements including 
a base computer, a portable rescue scene computer, an 
automated external defibrillator (AED), and a communica- 
tion link for linking the rescue scene computer to the base 
computer and/or the AED. The system and method further 
includes software that is programmed in the base computer 
and rescue scene computer to operate the single screen user 
interface and database. 

16 Claims, 17 Drawing Sheets 
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AUTOMATIC EXTERNAL DEFIBRILLATOR 
FIRST RESPONDER AND CLINICAL DA3A 
OUTCOME MANAGEMENT SYSTEM 

RELATED APPUCATION 

This application claims the benefit of U.S. Provisional 
Application No. 60/080,130, filed Mar. 31, 1998, incorpo- 
rated herein in its entirety by reference. 

FIELD OF THE INVENTION 

The present invention relates to medical emergency event 
maDagcment and, in particular, relates to a computer-based 
communications network and database for management of 
emergency medical events such as sudden cardiac arrest 15 
rescue events. 

BACKGROUND OF THE INVENTION 

Cardiac arrest, exposure to high-voiUge power lines, and 
other trauma to the body can result in ventricular fibrillation 20 
which is the rapid and uncoordinated contraction of the 
myocardium. The use of external defibrillators to restore the 
heartbeat to its normal pace through the application of 
electrical shock is a well-recognized and important tool in 
resuscitating patients. External defibrillation is used in emer- ^5 
gency settings in which the patient is either unconscious or 
otherwise unable to communicate. 

Automated external defibrillators (AEDs) are used by first 
rcsponders such as police officers, paramedics, and other 
emergency medical technicians to resuscitate cardiac aircst 
patients. The AED must be used quickly and properly by the 
first responder, since the chance of successfully resuscitating 
the patient decreases approximately 10 pcrcent-per-minute 
following cardiac arrest. 

With the advent of emerging technologies such as AEDs, 
emergency medical systems (EMS) have greater opportuni- 
ties for saving lives. However, because of increasing health 
care costs, an elevated standard of care, and competitiveness 
in the health care provider market, EMS directors must ^ 
improve their management of cardiac rescue events with 
AEDs. 

Unfortunately, current attempts at managing performance 
of sudden cardiac arrest rescues suffer from a lack of 
coordination and cohcsiveness that is necessary to accu- 45 
rately and comprehensively track and evaluate out-of- 
hospilal cardiac arrest rescues. For example, data regarding 
a cardiac rescue attempt typically arrives to the EMS direc- 
tor from several sources, occurring at difterenl points in 
time, and commonly in diflfereni formats which must be 50 
integrated away from the cardiac rescue site. Moreover, 
current techniques of reviewing cardiac rescue events lack 
the appropriate data to make significant strides in improving 
the quality of oul-of-hospital cardiac arrests. Finally, con- 
ventional computer-based tools for integrating and review- 55 
ing cardiac rescue data inflexibly require separate review 
and analysis of the incident, the AED and AED operator 
performance, and the EGG. 
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A method and system of the present invention manages 
cardiac rescue events. Unlike prior systems, this method and 
system uses a rescue scene computer to obtain patient and 
incident data at the rescue scene and then marry that data 
with ECG rescue dau and automated external defibrillator 65 
(AED) rescue data. All of these data are then simultaneously 
transmitted to a base computer at an emergency medical 



center for review. Accordingly, a reviewer at the base 
computer can immediately review the ECG and AED per- 
formance in context with patient and incident data. 

The method and system includes a Windows®-based 
single screen graphical user interface for entering and 
reviewing the data, and particularly includes a window for 
viewing ECG data simultaneously with entry and review of 
all other data available in the single screen user interface. 

In addition, as data (e.g., ECG, patient, incident, AED, 
etc.) are placed in the system, these data are insUntly 
registered by the system with corresponding NHSTA codes. 
This feature automatically readies the cardiac rescue data for 
reporting to national authorities. In addition, the NHSTA 
codes are embedded in the background of the active data 
fields to permit selective activation, deactivation, 
modification, and/or initialization. Moreover, appropriate 
data fields are supplied to insure all data for UTSTEIN-style 
reporting is obtained to permit UTSTEIN-style reporting of 
oul-of-hospital cardiac arrest. 

Finally, the system and method uses open database con- 
nectivity (ODBQ to permit any desired data fi-om a cardiac 
rescue event that are logged into other types of systems and 
methods to be imported into the method and system of the 
present invention. Similarly, data fi-om the system and 
method of the present invention can be exported to other 
ODBC-compatible data management systems and methods 
for further review, revision, or publication. 

The system and method comprises one or more of the 
following elements including a base computer, a portable 
rescue scene computer, an automated external defibrillator 
(AED), and a communication link for linking the rescue 
scene computer to the base computer and/or the AED, The 
system and method further includes software that is pro- 
grammed in the base computer and rescue scene computer to 
operate the single screen user interface and database. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic illustration of a cardiac rescue event 
data management system and method of the present inven- 
tion. 

FIG. 2 A is a schematic representation of a rescue scene 
location screen and patient information tab window, with 
optional simultaneous ECG display, of a graphical user 
interface of the system and method of the present invention. 

FIG. 2B is a schematic representation of a drop-down 
table for an incident type data field of the rescue scene 
location view screen of FIG. 2 A. 

FIG. 2C is a schematic representation of an edit window 
for the drop-down table of FIG. 2B showing a NHSTA code 
corresponding to the incident type data field entry. 

FIG. 3 is a schematic representation of an incident infor- 
mation tab window, with optional simultaneous ECG 
display, of a graphical user interface of the system and 
method of the present invention. 

FIG. 4 is a schematic representation of a patient vitals and 
therapy information tab window, with optional simultaneous 
ECG display, of a graphical user interface of the system and 
method of the present invention. 

FIGS. 5A-5B are schematic representations of a rescue 
dispatch information tab window, with optional simulta- 
neous ECG display, of a graphical user interface of the 
system and method of the present invention. 

FIGS. 6A— 6B are schematic representations of an auto- 
mated external defibrillator and operator performance tab 
window, with optional simultaneous ECG display, of a 
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graphical user interface of the system and method of the 
present invention. 

FIGS. 7A-7B are schematic representations of a patient 
outcome tab window, with optional simultaneoiis ECG 
display^, of a graphical user interface of the system and 
method of the present invention. 

FIG. 8 is a schematic representation of an AED and AED 
operator review tab window, with optional simultaneous 
ECG display, of a graphical user interface of the system and 
method of the present invention. 

FIG. 9 is a schematic representation of a reviewer note tab 
window, with optional simultaneous ECG display, of a 
graphical user interface of the system and method of the 
present invention. 

FIG. 10 is a schematic representation of a report of the 
system and method of the present invention for reporting 
UTSTEIN data on cardiac arrest incidents. 

FIG. 11 is a schematic representation of an AED deploy- 
ment tool window of the method and system of the present 
invention. 

FIG. 12 is a schematic representation of an AED training 
tool window of the method and system of the present 
invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A method and system for managing cardiac rescues of the 
present invention is schematically shown in FIG. 1 at 20. 
System 20 includes AED 22, AED data card 24, and rescue 
scene computer 26, all locatable at cardiac rescue scene 28. 
System 20 further includes land line communication link 30 
or wireless link 32 and base computer 34 at database 
management or emergency medical center 36. 

Both rescue scene computer 26 and base computer 34 
further include display 38 with graphical user interface 40 
(i.e., view screen) and input means 42 such as a keyboard for 
entering data into the view screen of the user interface. AED 
22 further includes a cable 43 for communicating with 
rescue scene computer 26. 

AED 22 preferably includes an AED such as the one 
disclosed in Olson, el. al, U.S. Pat. No. 5,645^71, titled 
AUTOMATED EXTERNAL DEFIBRILLATOR WITH 
UD ACnVATED SELF-TEST SYSTEM, which is hereby 
incorporated by reference in its entirety. AED 22 is capable 
of recording an ECG on a patient, and advising and deliv- 
ering an electrical shock as necessary. The AED also makes 
an audio recording at the cardiac rescue scene of an opera- 
tor's or bystander's voice during the ECG, Data from the : 
cardiac rescue event, including the ECG recorded in real 
time, data from AED-dctectable events (e.g., check 
electrodes, place electrodes, rhythm analyzed, shock 
advised, shock delivered, etc.), and the audio recording are 
recorded internally within AED 22 for later downloading to ; 
a computer for further analysis. The data can also be stored 
onto a data storage card that is removably insertable into 
AED 22, such as AED memory data card 24. AED memory 
data card 24 is, in turn, removably insertable into rescue 
scene computer 26, or into base computer 34, for transfer- ( 
ring the ECG and AED performance data from AED 22 into 
the respective rescue scene computer 26 or base computer 
34. Alternatively, the data can be downloaded from AED 22 
into rescue scene computer 26 via cable 43. 

Rescue scene computer 26 and base computer 34 are both € 
general purpose personal computers well known in the art. 
For example, both rescue scene computer 26 and base 
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computer 34 include, at a minimum, a CPU such as a 
486SX-66 MHz (or faster) processor. Rescue scene com- 
puter 26 and base computer 34 also include sufficient RAM 
memory (e.g., 16 megabytes) and hard drive memory (e.g., 
5 80 megabytes) to store and operate Microsoft® Windows 95 
or NT and the database software (e.g., Microsoft® Access) 
supporting the system and method of the present invention. 
Rescue scene computer 26 includes any portable computer 
such as a laptop personal computer (PC) or a handheld PC. 
jg During a cardiac rescue event, a first responder or other 
operator uses AED 22 to defibrillate a cardiac arrest patient. 
Data representing the ECG and the AED/AED operator 
performance are recorded internally within AED 22 and then 
transferred onto AED data card 24. Next, this ECG/AED 
J j data are transferred into rescue scene computer 26 via cable 
43, or by removal of AED data card 24 firona AED 22, and 
into rescue scene computer 26. In addition, while at the 
rescue scene, the first responder or other technician manu- 
ally enters patient and incident data regarding the cardiac 
rescue event into rescue scene computer 26. With all of the 
ECG daU, AED data, and non-ECG data (e.g., patient and 
incident information) loaded into rescue scene computer 26, 
this entire set of data is transmitted via landline link 30 or 
wireless link 32 to base computer 34 at a central emergency 
medical system center 36. 

The ECG data, AED data, and non-ECG data arc then 
observable together in an integrated fashion on base com- 
puter 34 in single screen graphical user interface 40. AH of 
this data can be reviewed or modified as necessary, while 
30 additional information regarding the cardiac rescue event, 
including post event care and related emergency medical 
system performance, can be entered by the iiser through the 
single screen user interface 40 using input means 42. Using 
this technique, data are comprehensively and accurately 
35 captured to permit meaningful and rapid evaluation of each 
cardiac rescue event. Over time, as the system and method 
of the present invention is applied across localities, states, 
and nationally, for multiple cardiac rescue events, a tremen- 
dous database will be developed. This information will 
40 greatly contribute to improving rescue techniques and 
understanding the delivery and effectiveness of emergency 
medical intervention. 

The remaining description explains single screen user 
interface 40 in greater detail, including how and where the 
45 ECG data, AED data, and non-ECG data are displayed as 
well as how other cardiac rescue event performance, 
evaluation, and reporting information is handled. 

FIG. 2 is a schematic representation of single screen 
graphical user interface 40 permitting entry, review, and 
50 revision of data regarding a cardiac rescue event. Interface 
40 defines single view screen 50 having resident 
components, such as rescue scene location 52, and selective 
viewing components, such as patient information tab win- 
dow 54, and optional ECG window 56. Tabs 55 mark access 
55 to selectable patient information tab window 54 as well as 
other selectable tab windows such as incident data window 
57, vitals and therapy window 58, dispatch summary win- 
dow 60, AED data window 62, review window 64, AED 
evaluation window 66, and notes window 68. Once a tab is 
50 selected, the window corresponding to that tab is displayed 
in an overlay fashion over the other lab windows. Data is 
entered via input means 42 into the data fields visible in the 
selected window, which correspond directly with data fields 
of the database that operates in the background (not visible). 
15 Data fields within the tab windows include stored data in 
drop-down windows that can be selected and/or are capable 
of receiving manually entered new data. 
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Al the rescue scene, an operator fills in the data fields of 
rescue scene location screen 52 using input means 42 of 
rescue scene computer 26 to collect general information 
about the palient and the incident. As shown in FIG. 2, 
rescue scene location screen 52 includes the following data 
fields: incident ID 80, incident date 82, incident time 84, 
incident type 86, service area 88, rescue address 90 (street, 
city, state, zip code, country, county), and geographic code 
92. Rescue scene location screen 52 always remains active 
in single screen user interface 40. Patient information tab 
window 54 includes the following data fields: patient name 
100, palient description 102 (such as dale of birth, age, 
gender, race), palient address 104 (street, city, state, zip 
code, county), and patient telephone 106. 

FIG. 2 also shows ECG pull-up window 56 which graphi- 
cally displays a real time representation of Ihe ECG recorded 
during the cardiac rescue event with AED 22, ECG pull-up 
window 56 includes the following data fields: real lime 
stamp 110, ECG waveform 112, and AED event stamp 114 
(e.g., electrodes placed, start of analysis, check electrodes). 
ECG window 56 defines a splitter window 115 that can be 
reduced or enlarged vertically on single screen user interface 
40. ECG window 56 also can be deactivated for selective 
removal from single screen user interface 40. All of the 
textual and graphically represented data in the ECG window 
56 is obtained from AED 22. 

When deployed in a handheld PC embodiment, rescue 
scene computer 26 operates a simpler graphical user inter- 
face like single screen user interface 40 that includes at least 
the corresponding data fields from patient information tab 
window 54 and incident information tab window 57 
(described below). 

The database supporting single screen graphical user 
interface 40 was constructed using Windows® operating 
system and Access® database system, both sold by 
Microsoft Corporation. Accordingly, the multiple tab win- 
dow structure within the single screen user interface 40, as 
well as the optional simultaneous ECG window 56, can be 
constructed by one skilled in the art using the tools and 
capabilities of Access® database program and Windows® 
operating system. In particular, the data access object (DAO) 
mode of the Access® program can be used to identify the 
desired data fields and relationship tables of the database, as 
well as the NHSTA codes further described below. The 
system and method of the present invention also includes an 
embedded registry of ccrUin National Highway Safety Traf- 
fic Administration (NHSTA) codes that is linked to corre- 
sponding cardiac/accident rescue data fields. The NHSTA 
codes used in the method and system of the present inven- 
tion are published in Federal Information Standard (FIPS) 
Publication 28, and in International Classification of Disease 
and Related Health Problems Ninth Revision (ICD-9) and 
the Tenth Revision (ICD-lO). The database is built in the 
open database connectivity format (ODBC) to permit data to 
be imported and exported entirely, or selectively, using an 
ODBC data management program such as Access®, 
FoxPro®, or SQL®, all known to those skilled in the art. For 
example, a common ODBC program can be used to extract 
all or some of the NHSTA-related data from the system. To 
do so, the user identifies the tables and data fields carrying 
an embedded NHSTA code (or other desired category of 
information) and marks them for extraction. Once all of the 
NHSTA-related data are exported, it can be further manipu- 
lated by the ODBC program into a format suitable for 
reporting to national, state or local authorities. Similarly, 
data can be extracted for other reporting purposes such as 
UTSTElN-style reporting to national, state or local 
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authorities, or for billing purposes with additional modifi- 
cation of the database of Uie method and the system of the 
present invention. 

The corresponding NHSTA codes for a given data field 
can be modified, added, or deleted by operating an edit list 
for the data field and then entering or editing the NHSTA 
code designation corresponding to that data field. For 
example, as shown in FIG. 2B, drop-down table 87A for the 
data field incident type 86 of rescue scene location 52 is 
selected, displaying several choices to fill this data field as 
well as "edit list" function 87B. By selecting the "edit Hst'* 
fiinction, another edit window, shown in FIG. 2C, is tilti- 
mately displayed on single screen user interface 40, which 
displays the data field, its entry, and the corresponding 
NHSTA code 87E for that entry. The default NHSTA code is 
displayed, if available, which can be modified, deleted, or 
added as necessary. 

FIG. 3 shows single screen tiser interface 40 with incident 
data tab window 57 selected and optional ECG window 56 
activated. Like patient tab window 54, incident tab window 
57 is used at the cardiac rescue scene to prompt the user to 
collect information about the incident, which will be trans- 
mitted to base computer 34 with patient data, ECG data, and 
AED data. Incident data tab window 56 includes the fol- 
lowing data fields: chief complaint 120, cause of injury 122, 
provider impression 124, pre-existing condition 126, signs 
and symptoms present 128, injury description 130, injury 
intent 132, incident/patient disposition 134, safety equip- 
ment 136, factors affecting EMS delivery 138, suspected 
alcohol/drug abuse 140. 

FIG. 4 show^ single screen user interface 40 with vitals 
and therapy tab window 58. The patient vitals and therapy 
data are typically collected at the cardiac rescue scene with 
the other patient data (tab window 54) and included for 
transmission with the ECG data to base computer 34. Once 
the vitals and therapy tab is selected, window 58 displays 
and includes the following data fields: respiratory rale 150, 
respiratory effort 152, blood pressure 154, skin perfusion 
156, with Glasgow evaluation 158 (including eye opening, 
verbal component, motor component, coma score, and 
revised trauma score), modified therapy list 160 (including 
therapy name, therapy time, therapy performer, and notes). 

FIG. 5A shows single screen user interface 40 with 
dispatch summary tab window 60 selected, and which 
includes the following data fields for first responder 170, 
second responder 172, and third responder 174: responder 
facility 176, vehicle type 178, dispatch ID 180, crew mem- 
bers 182, lights used 184, sirens used 186, transported 
patient 188, and location to which patient was transported 
190. As shown in FIG. 5B, a lower portion of dispatch 
siunmary tab window 60 includes additional data fields for 
each of first, second and third responder times 191 com- 
prising: unit dispatched 192, unit notified 193, unit respond- 
ing 194, arrival at scene 195, arrival at patient 196, dis- 
patched from scene 197, arrival at destination 198, and unit 
back in service 199. The data in the dispatch summary lab 
window can be entered into the system by rescue personnel 
either al the cardiac rescue scene and during continuing 
emergency medical service (e.g., transport to a hospital), or 
can be entered into the single screen user interface at base 
computer 34 at a later lime with information obtained from 
the rescue dispatch team after the rescue team reports its 
activities back to the rescue dispatch center. 

FIGS. 6A-6B show single screen user interface 40 with 
AED data tab window 62 selected, which includes the 
following data fields: AED serial number 200, model num- 
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ber 202, AED operator 204, and AED history 206 including 
event 208 (AED lid opened, electrodes placed . . . , shock 
advised), actual time 210 (i.e., real time), elapsed time 212, 
and comments 214 as well as first defibrillating shock time 
215, initial rhythm 216 (e.g., ventricular fibrillation), initial 
rhythm converted to rhythm 217 (e.g., ventricular 
fibrillation). Additional data fields in AED data tab window 
62 primarily relate to UTSTEIN-style reporting of out-of- 
bospital cardiac arrests, and include: provider type of first 
CPR 218, time of first CPR 219A, time CPR discontinued 
219B, witness type of cardiac arrest 220, witnessed cardiac 
arrest 221, confirmed cardiac arrest 222, initial cardiac 
rhythm shocked 223, and return of spontaneous circulation 
(ROSC) 224, cardiac etiology 225, resuscitation attempted 
226. Finally, tab window 62 includes display AED operating 
parameters look-up window 227, and battery information 
look-up window 228. Most of the AED- and ECG-related 
data fields in AED data tab window 62 is automatically 
entered into the method and system of the present invention 
when this data is downloaded fi^om AED 22 into rescue 
scene computer 26 and/or base computer 34. Of course, 
those data fields not filled in by data from AED 22 are filled 
in manually by an operator at the rescue scene or at a later 
lime by a reviewer. 

FIG. 7 A shows single screen user interface 40 with review 
tab window 64 selected, which includes the following data 
fields: dale of review 230, emergency room information 232, 
intensive care unit information 234, hospital information 
236. This information is entered into the system by the 
reviewer away fi^om the cardiac rescue scene. Emergency 
room information 232 , intensive care unit information 234, 
and hospital information 236 each include the following data 
fields: admitted to ER (or ICU or hospital) 240, name of ER 
(or ICU or hospital) 242, admission date 244, admission 
time 246, discharge date 248, discharge time 250, and 
patient died within 24 hours 252. Hospital information 236 
further includes the data field, alive after one year of 
discharge 254. FIG. 7B shows a lower portion of review tab 
window 64, which includes the following additional data 
fields: updated Glasgow evaluation 255 (including eye 
opening, verbal, and motor components, with total score), 
patient status 256 (including alive, alive after first year, 
scene of death, date of death, and time of death), and review 
status 258 (including review completed, review due date, 
reviewer name). 

FIG. 8 shows single screen user interface 40 with AED 
and responder evaluation tab window 66 selected, and which 
includes the following data fields: bystanders sUnd clear 
instruction 260, airway intervention 262, patient not 
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CPR. This report follows the Utstein Style Guidelines for 
Uniform Reporting of Data from Out-of-Hospital Cardiac 
Arrest. Reports similar to report 300 are available for 
ventricular tachycardia with bystander CPR, ventricular 
fibrillation with no-bystander CPR, ventricular fibrillation 
with bystander CPR, asystole with no-bystander CPR, and 
asystole with bystander CPR. Each UTSTEIN report 
includes the following data fields: service area 310, popu- 
lation served 312, confirmed cardiac arrests considered for 
resuscitation 314, resuscitations attempted 316, resuscita- 
tions not attempted 318, cardiac etiology 320, non-cardiac 
etiology 322, arrest witnessed (bystanders) 324, arrest not 
witnessed 326, arrest witnessed (EMS personnel) 328, initial 
rhythm VT330, other initial rhythms 332, no bystander CPR 
334, bystander CPR 336, any resuscitation on spontaneous 
circulation (ROSC) 338, never achieved (ROSC) 340, 
admitted to ICU/ward 342, efforts ceased 344 (expired in 
field or in ED), discharged alive 346, expired in hospital 348 
(total or within 24 hours), alive at one year 350, and expired 
within one year of discharge 352. 

Many other reports can be obtained which provide a print 
out of a selected combination of data fields from one or more 
lab windows of single screen user interface 40. For example, 
standard reports include dispatch summary, incident 
summary, post-market surveillance, ECG summary, and 
patient follow-up, etc. 

In addition to managing the effectiveness of a single or 
multiple cardiac rescue event, the system and method of the 
present invention also can be used to track the use and 
location of AEDs as well as facilitate training of AED 
operators. 

FIG. 11 shows single screen user interface 40 with 
optional AED deployment tracking tool window 400 
selected, which includes the following data fields: AED 
operator 402, AED/Battery information 404, and AED loca- 
tion 406. AED/battery information 404 further includes 
serial number 410, model number 412, AED ID 414, and 
battery ID 416. AED location 406 further includes type of 
location 418 (e.g., ground), VIN 420, address 422 (street, 
city, state, zip, telephone), and geographic code 424. Of 
course, most of this AED data will be loaded into these data 
fields automatically when the AED data from AED 22 is 
transmitted fi'om AED 22 into rescue scene computer 26 and 
then into base computer 34. 

FIG. 12 shows single screen user interface 40 with 
optional operator training tool window 430 selected, which 
includes the following data fields: operator trained 432 
(name, ID, title) and both AED training specifics 434 and 



conscious, not breathing, and no pulse 264, AED function 50 CPR training specifics 436, each including training per 



properly 266, incident investigation required 268, AED 
deliver one or more shocks 270, AED applied to appropriate 
patient 272, CPR initialed at appropriate time 274, CPR 
resumed at appropriate times 276, EMS arrive at patient's 
side during incident 278, and score 280. Tliis evaluation tab 55 
window is used for evaluating the AED and AED operator 
performance. 

FIG. 9 shows single screen user interface 40 with notes 
tab window 68 selected. This lab window is for provided for 
a reviewer to make notes regarding any aspect of the cardiac eo computer. Tliis on-scene data collection and simultaneous 
rescue under review. transmission with the ECG data permits the AED to remain 

The system and method of the present invention is also in the field for nearly immediate use in another cardiac 
capable of generating many types of reports by grouping a rescue event. Second, once the ECG data, AED data, and 
selected combination of data fields from one or more tab non-ECG data (patient and incident information, etc.) are in 
windows from single screen user interface 40. FIG. 10 65 the system, the ECG data is selectively displayed simulta- 
shows an UTSTEIN data report 300 on cardiac arrest neously with AED data and/or non-ECG patient and incident 
incidents for ventricular tachycardia with no-bystander data on a single screen graphical user interface. This feature 



formed by, date of last training, total number of hours 
trained, further training by. This data facilitates training of 
AED operators and tracking of who and how many people 
are trained AED operators. 

The system and method of the present invention have 
numerous advantageous feamres. First, a programmed res- 
cue scene computer permits user-observed patient and inci- 
dent data to be transmitted simultaneously with transmission 
of ECG data and AED data from the rescue scene to a base 
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greatly facilitates review of the data and ECG since the 
reviewer need not switch back and forth between a non-ECG 
data or notes/review screen and the ECC data screen during 
review. Third, ECG data and AED data imported from the 
AED, as well as non-ECG data such as patient and incident 5 
data, are automatically registered with corresponding pre- 
determined NHSTA codes (or other desired codes) to permit 
later reporting of the cardiac rescue data in national report- 
ing formats. The NHSTA code registry can be modified on 
a code-by-code basis and can be selectively deactivated, lo 
Fourth, the data fields are based on an Open Database 
Connectivity (ODBC) format to permit import and export of 
cardiac rescue data to and from other emergency medical 
event database management systems, as well as permitting 
customized reporting by using another ODBC reporting 15 
database management software. Together, these features 
elevate cardiac emergency medical system management to a 
new level, providing comprehensive and coherent integra- 
tion of all event and post-event data into a single system. 
This system and method permits internal or national report- 20 
ing and rapid assessment and evaluation of the cardiac 
rescue event. Over time, this system and method will 
contribute greatly to future benchmarking of cardiac rescue 
event responses and management, particxilarly those involv- 
ing AEDs. 25 
What is claimed is: 

1. A method of managing cardiac rescue events compris- 
ing the steps of: 

performing a cardiac rescue on a patient at a cardiac 
rescue site with an automated external defibrillator ^0 
(AED); 

collecting ECG data at the cardiac rescue event at the 

cardiac rescue site; and 
collecting automated AED rescue data of the cardiac 

rescue event at the cardiac rescue site presenting the 

ECG data and AED rescue data on a screen of a rescue 

scene computer at the cardiac rescue site. 

2. The method of claim 1 and further comprising: 
displaying the ECG data graphically on a display screen 4q 

simultaneously with the non-ECG rescue data. 

3. The method of claim 1 further comprising: 
reviewing the cardiac rescue event by viewing the ECG 

data on the display screen; and 
inputting analytical observations regarding the cardiac 
rescue event during the reviewing step. 

4. The method of claim 2 further including displaying the 
ECG data graphically in real time. 

5. The method of claim 1 further including the step of 
displaying the ECG data and AED rescue data in a real time 50 
enactment of the cardiac rescue event. 

6. The method of claim 1 further comprising: 
collecting AED rescue data including at least one of the 

following: 

patient information, rescue scene location information, 
incident and rescue scene assessment information, 
patient vitals and therapy information, therapy 
information, rescue dispatch and response information, 
and AED operator performance information. 

7. The method of claim 6 further comprising: 
collecting incident information/rescue scene assessment 

including chief complaint, cause of injury, provider 
impression, pre-existing condition, signs and 
symptoms, injury description, injury intent, incident/ 



patient disposition, safety equipment, factors affecting 
EMS delivery, suspected drug or alcohol abtise. 

8. The method of claim 1 further comprising: 
collecting patient vitals and therapy information including 

respiratory rale, respiratory effort, blood pressure, skin 
perfusion and Glasgow information including eye 
opening, verbal component, motor component, coma 
score, and therapy including therapy provider, therapy 
name, and lime of therapy. 

9. The method of claim 1 further comprising: 
collecting dispatch and response information including at 

least one of the following: responder facility, vehicle 
type, dispatch ID and crew members, lights used, sirens 
used, location of hospital patient transported to, unit 
dispatched, unit notified, unit responding, arrival at 
scene, arrival at patient, departiu-e from scene, arrival at 
destination, and unit back in service. 

10. The method of claim 1 further comprising: 
collecting AED rescue data including at least one of the 

following: an AED serial number, AED model number, 
AED operator, the real time of and occurrence of the 
following events: AED lid opening, electrode place- 
ment on patient, start of analysis, electrode checking, 
start of charge, advising operator of shock, delivering 
shock to patient. 

11. The method of claim 1 further comprising: 
collecting AED rescue data including at least one of the 

following: first defibrillating shock time, initial rhythm, 
initial rhythm conversion. 

12. The method of claim 1 further comprising: 
collecting AED rescue dala including at least one of the 

following: provider type of first CPR, time of first CPR, 
time CPR discontinued, 
witness type of cardiac arrest, witnessed cardiac arrest, 
confirmed cardiac arrest, initial cardiac rhythm 
shocked, return of spontaneous circulation, cardiac 
etiology, and resuscitation attempted. 

13. The method of claim 1 further comprising: 
collecting review data including at least one of the fol- 
lowing: review date; admitted to ER, ICU, or hospital; 
name of ER, ICU, or hospital; admission date; admis- 
sion time; discharge dale; discharge time; patient died 
within 24 hours; alive after one year of discharge; 
update Glasgow evaluation including eye opening, 
verbal, and motor components; patient status including 
alive, alive after first year, scene of death, date of death, 
and time of death; and review status including review 
completed, review due date, reviewer name, 

14. The method of claim 13 further comprising: 
establishing a link between a predetermined NHTSA code 

to a corresponding ECG data or AED rescue data. 

15. The method of claim 1 further comprising: 
operably communicatively coupling the AED to the res- 
cue site computer for the automated interchange of 
certain data therebetween; and 

embedding the predetermined NHSTA code in a back- 
ground of active data fields to permit selective 
activation, deactivation, modification, and/or initializa- 
tion thereof. 

16. The method of claim 1 further comprising simulta- 
neously presenting the ECG dala and AED rescue on a single 
screen graphical user interface of the rescue scene computer. 



♦ 




UNITED STATES PATENT AND TRADEMARK OFFICE 

CERTIFICATE OF CORRECTION 



PATENT NO. : 6,321,113 Bl 
DATED : November 20, 2001 



Page 1 of 1 



INVENTOR(S) : William S. Parker, Patrick J. Splinter, Sara M. Lindseth and Matthew G. Bradley 



It is certified that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 



Title page. 

Item [75], Inventors, please change "Sarah Lindseth" to ~ Sara Lindseth — . 



Signed and Sealed this 



Sixth Day of August, 2002 



Attest: 




Attesting Officer 



JAMES E. ROG AN 
Director of the United States Patent and Trademark Office 



iinniiiiiiniiinuiiiiiiiinii 



US(K)6629131B1 



(12) United States Patent (lo) Patent No.: us 6,629,131 Bi 

Choi (45) Date of Patent: Sep. 30, 2003 



(54) REGISTRATION MAIL SYSTEM WITH A 
SENT E-MAIL CHECK FUNCTION ON 
INTERNET AND METHOD FOR THE SAME 

(75) iDVCBtor: Woo Jin Choi, Seoul (KR) 

(73) Assignee: Nexen Co., Ltd., Seoul (KR) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days, 

(21) Appl. No.: 09/390,666 

(22) Filed: Sep. 7, 1999 

(51) InUCV G06F 15/16 

^52) U S a 709/206; 709/207; 709/311; 

^ ^ ■ ' 707/104.1; 379/93.01; 379/93.24 

(58) Field of Search 709/206, 207, 

^ ^ 709/311; 379/93.01, 93.24; 707/104.1 



(56) 



References Cited 

U.S. PATENT DOCUMENTS 

5 781,901 A • 7/1998 Kuzma , 358/402 

6,108,688 A * 8/2000 Nielsen 709/206 

6 175 859 Bl * 1/2001 Mohler 709/206 

e^lSsisSl Bl * 2/2001 Birrell et al 707/102 

6^202,086 Bl * 3/2001 Maruyama et al 358/434 



6,226,670 Bl • 5/2001 Ucno et al 340/10.1 

6,289,212 Bl * 9/2001 Stein et al 455/412 

6,308,206 Bl * 10/2001 Singh 709/223 

6,314,454 Bl * 11/2001 Wang el al 358/402 

6,332,164 Bl * 12/2001 Jain 709/203 

6,393,456 Bl * 5/2002 Ambler et al 709/200 

* cited by examiner 

Primary Examiner — Zami Maung 
Assistant Examiner—^insong, Hu 

(74) Attorney, Agent, or Fir/n— Schweitzer Cormnan Gross 
ABondellLLP 

(57) ABSTRACT 

An electronic mailing method on the Internet with a function 
of reception confirmation is described. The method is com- 
prising the steps of (a) assigning a unique code to the e-mail 
of a sender and recording the unique code in a database; (b) 
attaching to the e-mail a CGI executive program that auto- 
matically sends the unique code to the web server of the 
sender when the receiver receives the e-mail; (c) sending the 
unique code to the web server of the sender by the automatic 
execution of the CGI executive program when the e-mail is 
received by the receiver, and (d) comparing the unique code 
sent in the step (c) and the unique code recorded in the step 
(a) and, if they are identical, sending reception confirmation 
information to the sender. 
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REGISTRATION MAIL SYSTEM WITH A 
SENT E-MAIL CHECK FXTNCTION ON 
INTERNET AND METHOD FOR THE SAME 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a mail system and method 
for solving the problem that a sender cannot check whether 
or not a receiver received (read) a mail in an internet 
environment (FIG. 2) that is a switching system among mail 
servers independently operated . 

2. Description of Related Art 

Existing PC communication services (e.g., Chollian, 
Hitel, Nownuri, and Unitel in Korea) each provides a sent 
e-mail check function in exchanging mail between its own 
service users. This is possible because the service is a single 
mail system. However, the mail exchange between users of 
different services cannot be achieved. Namely, messages can 
be exchanged by e-mail only between users registered in the 
same service (FIG. 1). 

On the other hand, users can freely exchange their mes- 
sage by e-mail regardless of services in which they regis- 
tered according to the mail exchange system in the internet 
environment. Therefore, the existing PC communication 
services tend to provide an internet mail service together and 
the communication tends to be used based upon internet 
mail IDs (e-mail addresses). However, the existing internet 
mail service cannot provide a function allowing a sender to 
check whether or not a receiver read the mail sent by the 
sender. This is because internet mails are exchanged 
between independent mail servers. In this system, the sender 
cannot check the mail that the sender has sent to the 
receiver's mail server (FIG. 2). 

SUMMARY OF THE INVENTION 

Accordingly, the present invention is directed to a regis- 
tration mail system with a sent e-mail check function on 
internet and method for the same that substantially obviates 
one or more of the limitations and disadvantages of the 
related art. 

An objective of the present invention is to provide a 
registration mail system with a sent e-mail check function, 
wherein a unique code is given to each mail sent by a sender 
and recorded in a database (DB), a common gate interface 
(CGI) executive program through which the unique code 45 
and confirmation information arc sent to a source mail 
system if a receiver reads the mail is attached to the mail 
itself which is sent to the receiver's mail server, if the 
receiver reads the mail, the unique code and confirmation 
information that have been sent to the mail center by the CGI 
executive program are compared with database information 
and recorded in the database, and confirmation of reception 
by the receiver is notified to the sender. 

Additional features and advantages of the invention will 
be set forth in the following description, and in part will be 
apparent fi-om the description, or may be learned by practice 
of the invention. The objectives and other advantages of the 
invention will be realized and attained by the structure as 
illustrated in the written description and claims hereof, as 
well as the appended drawings. 

To achieve these and other advantages, and in accordance 
with the purpose of the present invention as embodied and 
broadly described, the present invention employs a mail 
control system for assigning a unique code to a mail sent by 
a sender, recording the code in a database, and attaching a 
CGI executive program to the mail. The mail control system 65 
organically acts with a mail server and is in linkage with a 
database. 
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The present invention also employs another mail control 
system for comparing reception confirmation information 
from a receiver with database information, recording the 
confirmation information in the database, and sending an 
informing signal to the sender. This mail control system 
organically acts with a web server and is in linkage with the 
database. 

When the receiver reads the mail in an off-line state, if a 
mail client application used by the receiver for reading the 
mail does not support a hypertext markup language 
(HTML), or if a text based emulator is used for reading the 
mail, the above system cannot be applied, so a registration 
mail system is developed as an extended type based upon the 
above system. In stead of using the program attached to the 
mail to process the reception confirmation information, the 
registration mail system stores the text of the mail therein 
and first sends only the information of a title of the mail, 
registration mail reception link, and registration mail guide 
note to the receiver. If the receiver requests the text of the 
mail, the registration mail system sends the text of the mail 
to the receiver and records the reception of the mail in the 
database. 

It is to be understood that both the foregoing general 
description and the following detailed description are exem- 
plary and explanatory and are intended to provide further 
explanation of the invention as claimed. 

BRIEF DESCRIPTION OF THE ATTACHED 
DRAWINGS 

The accompanying drawings, which are included to pro- 
vide a further understanding of the invention and arc incor- 
porated in and constitute a part of this specification, illustrate 
embodiments of the invention and together with the descrip- 
tion serve to explain the principles of the invention. 

In the drawings: 

FIG. 1 is a block diagram showing a conventional mail 
system in PC communication; 

FIG. 2 is a block diagram showing a conventional e-mail 
system in an internet environment; 

FIG. 3 is a block diagram showing an overall structure of 
a mail system with a sent e-mail check function according to 
the present invention; 

FIG. 4 is a block diagram showing an overall structure of 
an embodiment of a registration mail system with an 
extended sent e-mail check function according to the present 
invention; and 

FIG. 5 is a block diagram showing an overall structure of 
another embodiment of a registration mail system with an 
extended sent e-mail check function according to the present 
invention. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENT 

Reference will now be made in detail to the preferred 
embodiments of the present invention, examples of which 
arc illustrated in the accompanying drawings. 

With reference to the accompanying drawings, the present 
invention will be described in detail. 

FIG. 3 is a block diagram showing an overall structure of 
a mail system with a sent e-mail check function. Once a user 
composes a mail message and send it through this system, 
the mail is processed by a mail control system A which 
organically acts with a mail server. At this time, a unique 
code is assigned to the mail and the related information is 
recorded in a database. The mail control system A attaches 
the unique code and CGI executive program to the mail 
before sending it to the mail server of a receiver. If the 



us 6,629 

3 

receiver reads the arrived mail, the CGI executive program 
is carried out so as to send information confirming the read 
of the message by the receiver and the unique code of the 
mail to a mail control system B in a mail center. The 
received mail code is compared with the mail codes previ- 5 
ously recorded in the database to find the same mail code. 
Reception confirmation infonnation is added to the corre- 
sponding mail record in the database. Thereafter, the mail 
control system B sends a reception confirmation signal to the 
sender. Furthermore, the sender can check the sent mail after 
accessing the web server anytime when necessary (FIG. 3). 

A registration mail system extended from the above 
system is similar to the above system in that a imique code 
is assigned to a mail sent by a sender. However, differently 
from the above system, the text of the mail is separately 
stored and a registration mail reception link and a registra- 
tion mail guide note (indicates registration mail receive 
method for a user checking e-mail with an emulator based 
upon text) are attached to the mail in the mail center before 
sending the mail to the receiver's mail server. Once the 
receiver receives (reads) the mail, the text of the mail stored 20 
is requested through the registration mail reception link 
attached to the mail. The mail text is then received by the 
receiver through direct connection. At this time, the mail 
control system B compares the unique code of the mail with 
the mail codes in the database and adds reception confir- 25 
mation information to the record of the corresponding mail 
in the database. Subsequently, the mail control system B 
sends the reception confirmation signal to the sender. 
Furthermore, the sender can check the sent mail after 
accessing the web server anytime when necessary (FIG. 4). 3Q 

However, if a mail client application used by the receiver 
for checking e-mail does not support HTML, or if the 
receiver checks the e-mail using the text based emulator, the 
above system cannot be applied. In this occasion, once the 
receiver just replies according to the content of the regis- 
tration mail guide note, the mail control system A requests 
the text of the mail stored in the DB and sends it to the 
receiver. The mail control system A compares the unique 
code of the mail with the mail codes recorded in the DB and 
adds the reception confirmation information to the record of 
the corresponding mail. Tliereafter, the mail control system ^ 
B sends the reception confirmation signal to the sender. 
Furthermore, the sender can check the sent mail after 
accessing the web server anytime when necessary (FIG. 5). 

Consequently, the present invention makes it possible to 
use a sent mail check function on intcrael, thereby over- 
coming the defect of the internet e-mail that has been the 
main method for mail exchange. 

As illustrated, the present invention embodies an internet 
mail system supporting a sent mail check function. This is 
sufficiently important to the part of e-mail as means of ^° 
commimication. For example, when the e-mail is used for 
business, there may be some cases the success of the 
business depends on whether or not the receiver reads within 
a certain time limit. There may be some cases that reception 
itself is refused or that a sender cannot check whether or not 55 
the receiver reads the mail by phone or other means. The 
sent mail check function is very important to the sender in 
these cases as well as daily mail exchange. In case a receiver 
uses a plurality of e-mail addresses, the present invention 
makes it possible for a sender to find and send e-mail to the gQ 
receiver's c-mail address that is not used frequently. As 
illustrated, the sent mail check function is very useful. As 
internet e-mail becomes more important and necessary as 
means of communication, effect of the sent mail check 
function achieved by the present invention increases. 

It will be apparent to those skilled in the art that various 
modifications and variations can be made in the registration 



,131 Bl 

4 

mail system with a sent e-mail check function on internet 
and method for the same of the present invention without 
deviating from the spirit or scope of the invention. Thus, it 
is intended that the present invention covers the modifica- 
tions and variations of this invention provided they come 
within the scope of the appended claims and their equiva- 
lents. 

What is claimed is: 

1. An electronic mailing method on the Internet with a 
frinction of reception confirmation comprising: 

(a) assigning a unique code to an e-mail of a sender and 
recording in a database the infonnation on the unique 
code assigned to the e-mail; 

(b) attaching to the e-mail, to which the unique code was 
assigned in the step of (a), a CGI (common gateway 
interface) executive program that automatically sends 
to the web server of the sender the unique code that was 
assigned in the step (a) when the receiver receives the 
e-mail; 

(c) sending the unique code of the received e-mail to the 
web server of the sender by the automatic execution of 
the CGI executive program when the e-mail, to which 
the unique code was assigned in the step of (a) and to 
which the CGI executive program was attached in tbe 
step of (b), is received by the receiver; and 

(d) comparing the unique code of e-mail that was sent in 
the step (c) and the unique code that was recorded in the 
step (a) and, if they are identical, sending reception 
confirmation information to the sender. 

2. An electronic mailing method on the Internet with a 
function of receipt confirmation, comprising the steps of: 

(a) assigning a unique code to an e-mail sent by a sender 
and storing the unique code in a database; 

(b) attaching a CGI executive program to the e-mail 
containing the unique code of step (a) in order to 
transmit the imique code which is assigned to tbe 
e-mail in step (a), to an e-mail system of the sender 
upon a receiver's receipt of the e-mail; 

(c) transmitting the unique code of the e-mail received by 
the receiver to the e-mail mail system of the sender by 
an automatic execution of the CGI executive program 
upon the receiver's receipt of the e-mail which contains 
the unique code and the CGI executive program of step 
(b); and 

(d) delivering receipt confirmation infonnation to the 
sender of the e-mail if the unique code of the e-mail 
transmitted in step (c) is identical to the information 
stored in the database. 

3. An electronic mailing system on the Internet with a 
function of receipt confirmation, comprising: 

a first mail control system having a mail processor part 
which assigns a unique code to e-mail sent by a sender, 
attaches a CGI executive program for e-mail transmit- 
ting the assigned unique code to the electronic mailing 
system upon a receiver's receipt of the e-mail, and 
transmits the e-mail to the receiver's mail server; 

a database in which the unique code assigned by the mail 
processor part is recorded; and 

a second mail control system having a receipt confirma- 
tion part which receives the unique code of the e-mail 
transmitted by automatic execution of the CGI execu- 
tive program, compares the transmitted unique code 
with tbe unique code recorded in the database, and 
transmits receipt confirmation information to the 
sender if the two unique codes are identical. 

***** 
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CORBA n. Acronym for Common Object Request Broker 
^^hitecture. A specification developed by the Object 
iVlanagenient Group in 1992 in which pieces of programs 
(oiyects) comjnunicate with other objects in other pro- 
\^sffaSy even if the two programs are written in different 
^^^gianmiing languages and are running on different plat- 
^l^i^iiis. A program makes its request for objects through an 
t^^ject request broker^ or ORB, and thus does not need to 
J^@vv the structure of the program from which the object 
'%^0ss. CORBA is designed to work in object-oriented 
^^^yFijronments. See also HO^, object (definition 2), Object 
^^M^ement Group, object-oriented. 



One of the types of memory built into computers 
s random access memory (RAM) was available or 
^^dable. Some people still use the term to refer to the 
^Irteinory of any computer system, as in the phrase 
"^imp — a listing of the raw contents of main memory 
^jficnnent of a system crash. Compare RAM. 

pbij^s n. In the Java programming language, a public 
llliterface that is a standard member of the lan- 
^pre classes, at minimum, are available on all 

jfeystems where the Java platform runs. A pro- 
^0|^n entirely in the Java programming language 
j^^on core classes. See also class (definition IX 
-oriented programming. 

|m n. A program or program segment that is 
adorn access memory (RAM). 

Of or pertaining to a condition in which 
|jfegrams are loaded . in memory at the same 

In laser printers, a wire though which high 
^|^sM;to ionize the air and transfer a uniform 
to the photosensitive medium in prep- 

ser. 

^|putine that is in memory at the same time 
^^xecuted concurrently with, another 

^ifn^nce n. The process of diagnosing 
pouter problems after they occur. Com- 
$tenance. 

liidlfty n. See print quality. 

^iess wherein data in memory or on 
' changed, with its meaning thereby 



cost-benefit analysis n» The comparison of benefits to 
costs for a particular item or action. Cost-benefit analysis 
is often used in MIS or IS departments to determine such 
things as whether purchasing a new computer system is a 
good investment or whether hiring more staif is necessary. 
See also IS, MIS. 

coulomb n. A unit of electrical charge equivalent to 
roughly 6.26 x 10^^ electrons, with a negative charge 
being an excess of electrons and a positive charge being a 
deficiency of electrons. 

counter n. 1. In progranmfiing, a variable used to keep 
count of something. 2. In electronics, a circuit that counts 
a specified number of pulses before generating an output. 
3, A device that keeps track of the number of visitors to a 
World Wide Web site. 

counting loop n. In a program, a group of statements that 
are repeated, thereby incrementing a variable used as a 
counter (for example, a program might repeat a counting 
loop that adds 1 to its counter until the counter equals 10). 
See also loop' (definition 1). 

country code n. See major geographic domain. 

country-specific adj. Of, pertaining to, or characteristic 
of hardware or software that uses characters or conven- 
tions unique to a particular country or group of countries. 
Country'Specific does not necessarily refer to spoken lan- 
guages, although it does allow for special characters (such 
as accent marks) that are language-specific. Generally, the 
features considered country -specific include keyboard lay- 
out (including special-character keys), time and date con- 
ventions, financial and monetary symbols, decimal 
notation (decimal point of comma), and alphabetic sorting 
order. Such features are handled either by a computer's 
operadng system (for example, by the Keyboard and 
Country commands in MS-DOS) or by application pro- 
grams that offer options for tailoring documents to a par- 
ticular set of national or international conventions. 

courseware ru Software dedicated to education or training. 

courtesy copy n. See cc. 

CPA n. See Computer Press Association. 

CPCP n. 5ce HTCPCP. 

cpi n. See characters per inch. 

CP/M n. Acronym for Control Program/Monitor. A line ■ 
of operating systems from EHgital Research, Inc. (DRI), 



insider attack n. An attack on a network or system car- 
^ ried out by an individual associated with the hacked sys- 
tem. Insider attacks are typically the work of current or 
former employees of a company or organization who have 
knowledge of passwords and network vulnerabilities. 
Compare intruder attack. 

Ins key n. See Insert key. 

install vb. To set in place and prepare for operation. Oper- 
ating systems and application programs commonly 
include a disk-based installation, or setup, program that 
does most of the work of preparing the program to work 
with the computer, printer, and other devices. Often such a 
program can check for devices attached to the system, 
request the user to choose from sets of options, create a 
I place for the program on the hard disk, and modify system 
startup files as necessary. 

installable device driver n. A device driver that can be 
embedded within an operating system, usually in order to 
^ override an existing, less-fimctional service. 

Installable File System Manager n. In Windows 9x 
and Windows 2000, the part of the file system architecture 
responsible for arbitrating access to the different file sys- 
tem components. Acronym: IFS. 

installation program n. A program whose function is to 
install another program, either on a storage medium or in 
memory. An installation program, also called a setup pro- 
gram, might be used to guide a user through the often 
complex process of setting up an application for a particu- 
lar combination of machine, printer, and monitor. 

Installer n. A program, provided with the Apple Macin- 
tosh operating system, that allows the user to install sys- 
tem upgrades and make bootable (system) disks. 

Instance n. An object, in object-oriented programming, 
in relation to the class to which it belongs. For example, an 
object myList that belongs to a class List is an instance'of 
the class List. See also class, instance variable, instantiate, 
object (definition 2). 

Instance variable n. A variable associated with an 
instance of a class (an object). If a class defines a certain 
v^ariable, each instance of the class has its own copy of that 
t^ariable. See also class, instance, object (definition 2), 
>bject-oriented programming. 

nstantlate vb. To create an instance of a class. See also 
lass, instance, object (definition 2). 



instant messaging «. A service that alerts user^: when < 
friends or colleagues are on line and allows them to com-^^^ 
municate with each otiier in real time through private 3 
online chat areas. With instant messaging, a user creates 0 
list of other users with whom he or she wishes to commu- 1 
nicate; when a user from his or her list is on line, the ser- ■'^^ 
vice alerts the user and enables immediate contact with the 
otiier user. While instant messaging has primarily been a 
proprietary service offered by Internet service providers 
such as AOL and MSN. businesses are starting to employ 
mstant messaging to increase employee efficiency and 
make expertise more readily available to employees. 

Institute of Electrical and Electronics Engineers n. 

See IEEE. 

instruction n. An action statement in any computer lan- 
guage, most often in machine or assembly language. Most 
programs consist of two types of statements: declarations 
and instructions. See also declaration, statement 
instruction code n. See operation code. 
Instruction counter n. See instruction register 
instruction cycle n. The cycle in which a processor 
retrieves an instruction from memory, decodes it, and car- 
ries it out. The time required for an instruction cycle is tiie 
sum of the instruction (fetch) time and die execution 
(translate and execute) time and is measured by the num- 
ber of clock ticks (pulses of a processor's internal timer) 
consumed. 

instruction mix n. The assortment of types of instruc- 
tions contained in a program, such as assignment instmc- 
tions, mathematical instructions (floating-point or 
integer), control instructions, and indexing instructions. 
Knowledge of instruction mixes is important to designers 
of CPUs because it tells them which instructions should be 
shortened to yield the greatest speed, and to designers of 
benchmarks because it enables them to make die bench- 
marks relevant to real tasks. 

instruction pointer n. See program counter, 
instruction register n, A register in a central processing 
unit tiiat holds tiie address of the next instruction to be 
executed. 

instruction set n. The set of machine instructions tiiat a 
processor recognizes and can execute. See also assembler, 
microcode. 
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Web applications, since users access the Web from many 
types of computers. Java is used in programming small 
applications, or applets, for the World Wide Web, as well 
as in creating distributed network applications. See also 
bytecode, Java applet, Jini, object-oriented programming. 

Java applet n. A Java class that is loaded and run by an 
already-running Java application such as a Web browser or 
an applet viewer. Java applets can be downloaded and run 
by any Web browser capable of interpreting Java, such as 
[ntemet Explorer, Netscape Navigator, and HotJava. Java 
applets are frequently used to add multimedia effects and 
nteractivity to Web pages, such as background music, 
eal-time video displays, animations, calculators, and 
nteractive games. Applets can be activated automatically 
vhen a user views a page, or they may require some action 
>n the part of the user, such as clicking on an icon in the 
Veb page. See also applet, Java. 

avaBean n. A Java component architecture defined in 
jjie JavaBeans specification developed by Sun Microsys- 
2ms. A JavaBean, or Bean, is a reusable application com- 
onent — an independent code segment — that can be 
ombined with other JavaBean components to create a 
ava applet or application. The JavaBean concept empha- 
izes the platform-independence of the Java language, in 
'hich ideally a program, once written, can run on any 
Dmputing platform. JavaBeans are similar to Microsoft's 
ctiveX controls. ActiveX controls, however, can be 
iveloped in different programming languages but exe- 
ited only on a Windows platform. JavaBeans can be 
jveloped only in the Java programming language but ide- 
ly can run on any platform. See also ActiveX, Java. 

iva Card n. An application programming interface 
lPI) from Sun Microsystems, Inc., that allows Java 
plets and programs to run on smart cards and other 
vices with limited memory. Java Card uses a Java Card 
rtual Machine designed for severely memory-con- 
ained devices. See also applets, Java Card Virtual 
achine, smart card (definition 2). 

/a Card Virtual Machine n. An ultra-small-footprint, 
;hly optimized foundation of a runtime environment 
hin the Java 2 Platform Micro Edition. Derived from the 
a Virtual Machine (JVM), it is targeted at smart cards 
I other severely memory-constrained devices. The Java 
d Virtual Machine can run in devices with memory as 
ill as 24 KB of ROM, 16 KB of EEPROM, and 512 
iS of RAM. See also EEPROM, Java Card, RAM, 
Vf. 



Java chip 7z.-An implementation on a single integrated 
circuit of the virtual machine specified for execution oft 
Java programming language. Such chips, which are beu 
developed by Sun Microsystems, Inc., could be used in 
very small devices and as controllers for appliances. Seei 
also integrated circuit, Java, virtual machine. 

Java-compliant browser n. A Web browser with suppo] 
for the Java programming language built into it. Most 
current Web browsers are Java-compliant. See also Java, 
Web browser. 

Java Developer's Kit n. A set of software tools devel- 
oped by Sun Microsystems, Inc., for writing Java applets 
or applications. The kit, which is distributed free, includes 
a Java compiler, interpreter, debugger, viewer for applets, 
and documentation- Acronym: JDK. See also applet, Java, 
Java applet. 

Java Foundation Classes n. A Java-based set of class 
libraries developed by Sun Microsystems, Inc. Encom- 
passing fundamentals of the Internet Foundation Classes 
created by Netscape Communications Corp., the Java 
Foundation Classes extend the Java Abstract Window 
Toolkit (AWT) by providing graphical user interface 
components for use in developing commercial and 
Internet-related Java applications. See also Abstract Win- 
dow Toolkit, Application Foundation Classes, Internet 
Foundation Classes, Java, JavaBean, Microsoft Founda- 
tion Classes. 

Java HotSpot n. A Java performance engine introduced 
by Sun Microsystems, Inc., in 1999 that is designed to run 
Java applications faster than just-in-time (JIT) compilers. 
The core of Java HotSpot, and the feature for which it is 
named, is its ability to perform adaptive optimization — the 
identification and optimization of "hot spots," or sections 
of performance-critical code. Improved garbage collection 
(freeing of memory occupied by objects no longer in use) 
and better multithreading are additional features designed 
to contribute to increased performance. See also Java. 

Java IDL n. Short for Java Interface Definition Language. 
A Java technology that provides CORBA interoperability 
and connectivity capabilities for the Java platform. These 
capabilities enable Java applications to invoke operations 
on-remote network services using the Object Management 
Group Interface Definition Language and Internet Inter- 
ORB Protocol, See also CORBA, IDL, J2EE, RMT-IIOP. 

JavaMall n. An API in the Sun Microsystems, Inc., Java 
platform for sending and receiving mail. A set of 
abstract APIs that model a mail system, JavaMaiJ pro- 
vides a platform-independent and protocol-independent 
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page layout V 

page layout n. In desktop publishing, the process of 
arranging text and graphics on the pages of a document. 
Page-layout programs excel in text placement and man- 
agement of special effects applied to text. Although page- 
layout programs are generally slower than word-processing 
programs, they can perform such advanced tasks as flowing 
text into complex multicolumn page designs, printing doc- 
uments in signatures, managing color separations, and sup- 
porting sophisticated kerning and hyphenation. 

page makeup n. The assembling of graphics and text on 
a page in preparation for printing. 

page mode RAM n. A specially designed dynamic RAM 
that supports access to sequential memory locations with a 
reduced cycle time. This is especially attractive in video 
RAM, in which each location is accessed in ascending 
order to create the screen image. Page mode RAM can 
also improve the execution speed of code because code 
tends to execute sequentially through memory. See also 
cycle drae, dynamic RAM. 

page orientation n. See landscape mode, portrait mode, 
page printer n. Any printer, such as a laser printer, that 
prints an entire page at once. Because page printers must 
store the entire page in memory before printing, they 
require relatively large amounts of memory. Compare line 
printer. 

pager /I. Pocket-sized wireless electronic device that uses 
radio signals to record incoming phone numbers or short 
text messages. Some pagers allow users to send messages 
as well. Also called: beeper. 

page reader n. See document reader. 

page setup n. A set of choices that affect how a file is 
printed on the page. Page setup might reflect the size of 
paper going into the printer, the page margins, the specific 
pages in the document to be printed, whether the image is 
to be reduced or enlarged when printed, and whether 
another file is to be printed immediately after the first file 
is printed. 

pages per minute n. See PPM. 

Page Up key n, A standard key foften labeled "PgUp") 
on most computer keyboards whose specific meaning is 
different in different programs. In many cases, it moves 
the cursor up to the top of the previous page or a specific 
number of lines. 



pagination n. 1. The process of dividing a u«a 
pages for printing. 2, The process of adding^ 
bers, as in a running head. 

paging n. A technique for implementing vii 
The virtual address space is divided into a nu^ 
fixed-size blocks called pages, each of which^i 
mapped onto any of the physical addresses av3 
the system. Special memory management haiA 
(MMU or PMMU) perfbrixis the address transll 
virtual addresses to physical addresses. See alM^ 
management unit, paged memory management^ 
tual memory. 

paging file n. A hidden file on the hard disk i , 

ing systems (such as Windows, Mac OS X, and . 
use to hold parts of programs and data files that ^ 
in memory. The paging file and physical memory^ 
RAM, make up vinual memory. Data is moved fhj 
paging file to memory as needed and moved froniiiL 
to the paging file to make room for new data in 
Also called: swap file. See also virtual memory. 
paint^ n. A color and pattern used with graphics prL 
to fill areas of a drawing, applied with tools such as| 
paintbrush or a spraycan. 

paint^ vb. To fill a portion of a drawing with paint (c 
or a pattern). 

paintbrush n. An artist's tool in a paint program or 
another graphics application for applying a streak of 
color to an image. The user can usually select the widi ^ 
the streak. See also paint program. Compare sprayc 
paint program n. An application program that cieatw 
graphics as bit maps. A paint program, because it treal. 
drawing as a group of dots, is particularly appropriate^ 
fi-eehand drawing. Such a program commonly provides f 
tools for images requiring lines, curves, and geometric : 
shapes but does not treat any shape as an entity that can U 
moved or modified as a discrete object without losing 
identity. Compare drawing program. 

palette «. 1. In paint programs, a collection of drawing - 
tools, such as patterns, colors, brush shapes, and different 
line widths, from which the user can choose. 2. A subset ' \ 
of the color look-up table that establishes the colore that 
can be displayed on the screen at a particular time. The 
number of colors in a palette is determined by the number 
of bits used to represent a pixel. See also color bits, color 
look-up table, pixel. 
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(57) ABSTRACT 

An electronic messaging system, and related method, 
employs a handwriting server component operable on a 
network with an email host server, and a client component 
operable with an email client on a client computer connected 
to the network. The client component sets up a graphical 
data capture area into which a user can enter handwritten or 
handdrawn input through a suitable graphical input device. 
The handwritten or handdrawn input is captured and sent as 
pixel data or an attached graphics file with an email mes- 
sage. The preferred form of the handwriting messaging 
component is as a Java applet downloaded to the web page 
of the email client or installed as a plug-in with the email 
client- The graphical email message may be sent to a server 
having a Java-based handwriting server component, a 
Domino server, a real-time messaging server, a standard 
Internet email server, or an Internet email server with a WAP 
interface to wireless PDAs and other digital communications 
devices. The graphical input device can be a touch screen, 
pen input device, stylus pad, or even a standard mouse. The 
handwriting messaging component sets up a drawing editor/ 
viewer that allows the user to compose, manipulate, send 
and view handwritten or handdrawn messages. The drawing 
editor/viewer can include a set of standard drawing tools and 
functions. 

20 Claims^ 11 Drawing Sheets 
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METHOD AND SYSTEM FOR CREATING 
AND SENDING GRAPHICAL EMAIL 

This U.S. patent application claims the priority of U.S. 
Provisional Application No. 60/159,636 filed on Oct. 13, 
1999, entitled "Graphical Email Drawing and File Attach- 
ment Syslena", by the same inventor. 

FIELD OF THE INVENTION 

This invention relates generally to the processing of 
handwritten content as digital data in electronic messaging, 
and specifically to an electronic messaging system for 
graphical (handwritten or handdrawn) email. 

BACKGROUND OF THE INVENTION 

Electronic messaging is a general method for sending and 
receiving communications as digital data between comput- 
ers on a network. The Internet has dramatically increased 
electronic messaging amongst millions of users on global 
data networks. Many different forms of electronic messag- 
ing are being used to send and receive commumications in a 
wide variety of forms of structured and unstructured data. 
Businesses make extensive use of electronic messaging to 
conduct business communications and transactions between 
trading partners. Electronic mail (or email) is a popular form 
of electronic messaging for communications between users. 
Typical email messages are composed of typed text or a 
combination of typed text and text or graphical files that are 
attached to the email message and opened with the appro- 
priate processor or viewer. As the popularity of the Internet 
continues to grow worldwide, more and more people num- 
bering in the billions are expected to use email for commu- 
nications. 

Recent advances in technology and standards have 
expanded the types and forms of devices that can connect to 
the Internet. In addition to dial-up and online connections 
between users computers and servers that provide informa- 
tion services and email services, many types of other devices 
are being connected to the Internet for communications 
purposes, including personal digital assistants (PDAs), text 
messaging pagers, digital cellphones enabled with Wireless 
Application Protocol (WAP), advanced digital game 
machines, digital set top boxes for televisions, and even 
CPU-controlled household appliances. Many of these 
devices having Internet access do not require or are not 
adapted to use a keyboard for inputting data. While there are 
other types of input devices that enable handwritten or 
handdrawn input, such as touch sensitive screens, stylus 
pads, optical pens, etc., they have not been enabled for 
electronic messaging and other communication functions. 

Handwritten or handdrawn input can be more convenient 
to use than a keyboard and, in many situations, would be 
uniquely necessary for certain types of communication. 
Many written language systems, such as Japanese, Korean, 
Chinese, Arabic, Thai, Sanskrit, etc., use cursive or ideo- 
graphic characters that are very difficult to input by an 
equivalent method via keyboard. For example, text input of 
the Japanese written language requires the use of simulated 
phonetic spelling methods (romanji, hiragana, and/or 60 
katakana) to select from thousands of possible kanji char- 
acters. Many mobile devices such as PDAs do not have 
keyboards due to their limited size and form, or would 
become cumbersome to use if a keyboard must be attached 
or if text must be entered by cursoring through displays of 65 
softkcys- Disabled or hospitalized people who have limited 
hand mobility may not be able to use a keyboard effectively. 
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Current legal and financial institutions still rely heavily on 
the use of handwritten signatures to validate a person's 
unique identity. And in many instances, people find it much 
easier to communicate an idea by drawing a picture, or 
prefer handwriting or drawing a picture as more personal or 
expressive communication than typing text on a keyboard. 

There is thus a clear need for an electronic messaging 
system that allows people to communicate with their own 
handwriting or drawing, as contrasted to typed text. This 
need will continue to grow as the numbers of global users 
and Internet-connected devices increase. None of the current 
electronic messaging methods allow a user to compose, 
manipulate, store, send, receive, and view a handwritten or 
handdrawn email message. 

SUMMARY OF TOE INVENTION 

In accordance with the present inventioa, an electronic 
messaging system, and related method, comprises a hand- 
writing server component operable on a server computer on 
a network with an email host server for receiving an email 
message sent from a user and storing it for retrieval by a user 
to whom it is addressed, and a handwriting client component 
operable with an email client on a client computer for setting 
up a graphical data capture area into which a user can enter 
handwritten or handdrawn input through a suitable graphical 
input device, and for capturing the handwritten or hand- 
drawn input as graphical data and sending it via the network 
to the server component for handling as an email message. 
The client component is also operable for setting up a 
graphical data viewing area for viewing the graphical data 
sent with an email message handled by the server compo- 
nent. 

In another version of the invention, an electronic mes- 
saging device, and related method, comprises a handwriting 
messaging component operable in a web browser of a 
computer connected on a network for setting up a graphical 
data capture area into which a user can enter handwritten or 
handdrawn input through a suitable graphical input device, 
and for capturing the handwritten or handdrawn input as 
graphical data and sending it as an email message on the 
network. The handwriting messaging component can con- 
vert the graphical data to a GIF file that is attached to the 
email message and send the email message to a standard 
Internet email server. Alternatively, the handwriting mes- 
saging component can format the captured data as pixel data 
and send it to a handwriting server component of a server 
computer that can transmit it to a receiving computer 
enabled with a similar handwriting messaging component 
for retrieving the email message and viewing the pixel data 
as the corresponding handwritten or handdrawn image. 

In the preferred embodiments, the handwriting messaging 
component is a Java applet downloadable to a web page for 
an email client of a standard web browser, or may be a Java 
plug-in application installed with the web browser. The 
graphical input device can be a touch screen, pen input 
device, stylus pad, or even a standard mouse. The handwrit- 
ing messaging component sets up a drawing editor/viewer 
that allows the user to compose, manipulate, and view 
handwritten or handdrawn messages. The editorA^iewer can 
include standard drawing tools such as those for line size, 
color, paper and border selection, circle and polygon shapes, 
spray paint, flood fill, color palette, undo and scrolling 
functions. 

Other objects, features, and advantages of the present 
invention will be described in further detail below, with 
reference to the following drawings: 
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BRIEF DESCRIPTION OF DRAWINGS 

FIG. lA is a diagram illustrating the connection of client 
computers with pen devices to an email server computer on 
the Internet, and FIG. IB shows the email handling com- 
ponents of the client and server computers; 

FIG. 2A is a process flow diagram of an SMTP server 
version of the graphical email system, and FIG. 2B is a 
schematic illustration of the network connections of this 
version of the graphical email system; 

FIG. 3 A is a process flow diagram of a Lotus™ Domino 
server version of the graphical email system, and FIG. 3B is 
a schematic illustration of the network connections of this 
version of the graphical email system; 

FIG. 4A is a process flow diagram of a real-time mes- 
saging server version of the graphical email system, and 
FIG. 4B is a schematic illustration of the network connec- 
tions of this version of the graphical email system; 

FIG. 5 is a schematic illustration of the network connec- 
tions of an Internet email server version of the graphical 
email system; 

FIG. 6 is a schematic illustration of the network connec- 
tions of a WAP-enabled cellphone or PDA version of the 
graphical email system; and 

HG. 7 A is a schematic illustration of the user interface for 
the graphical data capture and drawing functions of the 
graphical email system; and FIG. 7B is an example of an 
editorA^ewer interface for the graphical email system on a 
personal digital assistant (PDA). 

DETAILED DESCRIPTION OF INVENTION 

Referring to FIG. lA, the general system architecture of 
the graphical email system (and related method) of the 
present invention is illustrated. A plurality of client comput- ; 
ers 110, 111, etc., adapted for handwriting or handdrawing 
input are used by users to connect via a network (the Internet 
or any type of multi-user network) to a server computer 120. 
In the context of this description, the term "computer" is 
used to refer to any type of data processing device which is 
capable of executing digitally programmed instructions. The 
term "client computer*' refers to any computer capable of 
connecting to a server computer on a network and perform- 
ing a function with the server computer. An example of a 
typical computer for use on a network is a Pentium or higher 
class PC with Windows operating system of Microsoft 
Corp., Redmond, Wash., or Macintosh or higher class PC 
with Macintosh OS operating system of Apple Computer 
Corp., Cupertino, Calif However, a client computer can also 
be a wide range of other network-connectable computing 
devices such as personal digital assistants (PDAs), text 
messaging pagers, digital cellphones enabled with Wireless 
Application Protocol (WAP), advanced digital game 
machines, digital set top boxes for televisions, and even 
CPU-controEed household appliances. The term "server 
computer" is used to refer to any type of data processing 
device that is connected to a node on a network for providing 
services to client devices on the network. 

In the present invention, the client computer 110 is what 
a sender or recipient uses to compose and send, and receive 
and view, handwritten or hand drawn email messages. T^e 
client computer preferably is of the type that can run a 
standard web browser which supports an email client, such 
as those compatible with Microsoft IE 4.x browsers, 
licensed by Microsoft Corp., of Bellevue, Wash., or < 
Netscape 4,x web browsers, licensed by America Online, 
Inc., of Fairfax, Va. The standard browsers preferably also 
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support the Java Virtual Machine, Version 1.2 or higher, 
licensed by Sun Microsystems, of Mountain View, Calif., 
which is the preferred platform for programming and dis- 
tributing the handwriting messaging software in the present 
invention as Java applets or Java-based plug-ins to the 
browsers. The standard web browsers connect to the net- 
work using any standard protocol recognized on the net- 
work. For example, on the Internet standard web browsers 
use the TCP/IP protocol. Connection to the network may be 
made by modem over a dial-up telephone line, DSL line, 
cable modem, Internet access connection, or a local area 
network. 

The handwriting or handdrawing input device can be a 
touch screen, pen input device, stylus pad, optical pointer, 
mouse, etc., which is attached to the client computer to allow 
the user to handwrite or handdrawn messages in a graphical 
data capture area of the email client of the web browser set 
up for that purpose. Examples of such input devices include 
the Wacom Graphire™ pen tablet sold by Wacom Technol- 
ogy Corporation, of Seattle, Wash., which attaches to the 
client computer via a serial or USB port. The pen device 
could also be integrated with a touch screen, e.g., as also 
offered by Wacom, or part of the computer itself, e.g., as 
offered with the Sharp SJ5, Copernicus and Pro Stations sold 
by Sharp Corporation, of Tokyo, Japan. 

The server computer is a central processing server for the 
graphical email system. It is connected to the network to 
communicate with the client computers using, for example, 
the TCP/IP protocol on the Internet. In the preferred 
implementation, the server computer stores the graphical 
email handling software that is downloaded to the client 
computers. It authenticates users against a directory of 
authorized users and manages and tracks the state of con- 
current user sessions- For sending and receiving graphical 
email, it communicates with the graphical email software on 
the client computers. When a handwriting message is com- 
posed on the client computer, the server computer receives 
the graphical email message and stores it in a database. 
When a handwriting message is to be viewed by the client 
computer, the server computer fetches the graphical email 
message from the database and sends the message to the 
client computer for display as a handwriting image. 

Referring to FIG. IB, the graphical email handling com- 
ponents of the preferred implementation of the invention 
system are illustrated. The client computer 210 includes a 
Handwriting Messaging Client 211 which handles sending 
and receiving graphical email messages, a Java Virtual 
Machine (VM) 212 which sets up the graphical data capmre 
area and display area for the handwriting message, and the 
Web Browser 213 which provides the user interface for 
connecting to the Internet (or other network). There are two 
versions of the Handwriting Messaging Client software 
described below, i.e., a Java applet and a Java application 
version. The Java applet version is used for sending and 
receiving handwritten email messages via a server comput- 
er's mail server functions. The Java application version of 
the handwriting messaging client software is installed with 
the users' browsers for real-time messaging between users 
or via a real-time Java server. The cUent software includes 
a drawing editor/viewer for composing and viewing hand- 
written email messages, as well as the functions to commu- 
nicate with a server in a server-client configuration. 

The server computer 220 includes an HTTP Server Inter- 
face 221 for connection to the Internet, a User Directory 222 
for identifying email addresses of authorized users, User 
Message Queues 223 for delivering received messages to 
users, a Downloadable Software Server 224 for download- 
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ing the graphical email software to client computers, a Mail 
Server Interface 225 for handling sent and received email, a 
Java "Virtual Machine (VM) 226 which provides the platform 
for interacting with the users' graphical email software, and 
a Handwriting Messaging Server 227 which formats email 
messages using the graphical data captured by the software 
on the client computers. There are four versions of the 
Handwriting Messaging Server described below, i.e., a 
Handwriting Java Server Version, a Domino Server Version, 
a Real-Time Java Server Version, and an Internet Email 
Server Version. 

Handwriting Java Client and Handwriting Java Server Ver- 
sion 

With reference to FIG. 2B, this version of the system uses 
both handwriting client and server software components 
along with the usual email server functions. A Handwriting 
Java Client 210a operates in a web browser (such as 
Netscape Navigator or Microsoft Internet Explorer) as a 
Java applet on the client computer 210. The applet 210a 
provides a drawing editor to compose and send handwritten 
email messages, and on the receiving end, also provides the 
drawing viewer to view the handwritten message. The 
implementation of a Java applet for the handwriting mes- 
saging function is described in further detail below. 
Generally, the use of a Java applet to provide a drawing 
application intended to run in a browser is known to those 
knowledgeable in this field. As one example, a Java applet 
used to set up a drawing editor in a browser for a "white- 
board" application run on an intranet is the SameTime'^** 
whiteboard applet offered with Lotus'^" Notes, a workgroup 
software suite distributed by Lotus Development Corp., of 
Cambridge, Mass., which is a division of IBM Corp., 
Armonk, N.Y. 

In the present invention, a Java applet is created specifi- 
cally for setting up a drawing editor/viewer operable with an 
email client running with a web browser for capturing, 
sending, receiving and viewing a handwriting or handdraw- 
ing email message. The Java applet consists of a set of 
modules which run the different messaging functions of the 
drawing editor/viewer. The data captxirc and sending module 
operates by first recognizing the handwriting input device 
connected to the client computer, then creating a temporary 
memory space for holding the input received from the input 
device, capturing the input signals from the input device 
(usually a series of coordinate data inputs representing 
time-sampled coordinate positions detected for the trace of 
the input device), converting the input signals to pixel data 
(screen coordinates, color, intensity), and displaying the 
pixel data in a display area or "panel" of the email client to 
show the handwriting or handdrawn image input by the user 
through the input device. The display allows the user send- 
ing a handwritten email message to verify what is being 
written, and is also the same display that allows a user 
receiving the handwritten email message to view the corre- 
sponding image. An example of a data capture and sending 
module according to the invention is illustrated in the source 
code listing appended hereto as Appendix I. 

When the graphical email message is completed, the user 
addresses the message to a recipient and sends it. The 
Handwriting Java Client formats and sends the email mes- 
sage with the pixel data to the Handwriting Java Server 
component 220a on the server computer 220, which con- 
verts the pixel data to a GIF file attachment to a standard 
email body. The Handwriting Java Server component 220a 
communicates with an SMTP email gateway computer 240 i 
to send email messages using the industry-standard SMTT 
Internet protocol. The SMTP email gateway sends the email 
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messages to mail servers 250, such as an industry-standard 
IMAP (Internet Message Access Protocol) mail servers like 
MS Exchange or Lotus Domino on the Internet. Email 
recipients can retrieve their email from the mail servers 250 
using a standard Internet email chcnt 260, such as Microsoft 
Outlook, Pegasus Mail, Eudora mail, or Lotus Notes. When 
the graphical email is retrieved with a standard Internet 
email client, the handwritten drawing is viewed as a file 
attachment using a GIF viewer operates with the web 
browser. Email recipients on client computers 230 who have 
the Handwriting Java Client 210^ in their web browser can 
receive their handwritten email messages directly. The 
graphical email message is retrieved from the Handwriting 
Java Server component 220a on the server computer 220 
and displayed in the Handwriting Java Client viewer as a 
handwritten or handdrawn image. 

With reference to FIG. 2A, the specific process steps 
involved with sending a handwritten email message and 
viewing it by the recipient are described in detail below: 

1. The Handwriting Java Client software is downloaded 
from the Handwriting Java Server to the client computer 
through a web page that is displayed in a web browser. 

2. The Handwriting Java Client software is initialized and 
establishes a connection to the Handwriting Java Server 
using the industry-standard TCP/IP and remote method 
invocation (RMI) protocols. After initialization is 
complete, the Handwriting Java Client software displays 
a drawing composition editor that is used to compose the 
handwritten message. 

3. The handwritten message is composed by the user in a 
graphical data capture area set up by the drawing editor, 
selecting the appropriate writing and drawing tools, 
colors, and styles as offered in the Handwriting Java 
Client software. 

4. While the user is drawing in the graphical data capture 
area, the pixel data representing the drawing is stored in 
local memory. When the graphical email naessage is 
completed, the user addresses the message to a recipient 
using Javascript fields on the web page in which the Java 
handwriting client is embedded. 

5. When the user issues a "Send" command, the Handwriting 
Java Qient formats the message and sends the pixel data 
to the Handwriting Java Server. The graphical message is 
still in GIF format at this time. 

6. The Handwriting Java Server processes the graphical 
message data using standard base64 encoding. This turns 
the data into ASCII text that can be transmitted as 
standard email data packets by the Handwriting Java 
Server. 

The Handwriting Java Server creates an outgoing email 
message that contains the encoded handwritten message 
as a GIF attachment. 

8. The Hai}d writing Java Server sends the outgoing email 
message with GIF attachment via the SMTP (Simple Mail 
Transfer Protocol) gateway 240. 

9. The SMTP gateway transfers the message to an IMAP 
mail server based on the recipient's address. The IMAP 
server alloAVs clients running it to retrieve mail from the 
host mail server also running the protocol, similar to 
POP-3, bul with extended capabilities. Recipients can 
open the email as a standard email message with a GIF 
attachment (steps 10a, 10b below) or with a Handwriting 
Java Client applet if downloaded to their web browser 
(steps 11a, lib, 11c below). 

10a. The IMAP server sends the email with the handwritten 
message as an attached encoded GIF file to an external 
email address for the recipient. 
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10b. When the recipient opens the email containing the 
attachment, the message can be displayed on their com- 
puter using a GIF viewer. 

11a. T^e IMAP server sends the email with the handwritten 
message as an attached encoded GIF file to an internal 5 
email address, i.e., to an address on a server computer 220 
that is running the Handwriting Java Server component 
220a. 

lib. The Handwriting Java Server decodes the attached GIF 
file into pixel data and sends it to Ihe Handwriting Java 
Client applet running in the recipient's web browser. 
11c. The Handwriting Java Client receives the pixel data 
firom the Handwriting Java Server and renders the pixel 
data as a handwritten or handdrawn image in the drawing 
editor/viewer 
Handwriting Java Client and Domino Server Version 

With reference to FIG. 3B, this version of the system uses 
the Handwriting Java Client 31 Oa along with a Lotus™ 
Domino Server on the server computer 320. As before, the 
Handwriting Java Client 310a operates in a web browser as 
a Java applet on the client computers 310330. The applet 20 
310fl provides a drawing editorMewer to compose and view 
handwritten messages. For sending and receiving email 
internally, the applet 310fl communicates with the Domino 
Server on the server computer 320. The Domino server 
sends email messages among users with client computers 25 
running Java cHenl software connected to the server's intra- 
net. The Domino Server communicates with an SMTP email 
gateway computer 340 to send email messages externally 
using the SMTP Internet protocol. The SMTP email gateway 
sends the email messages to mail servers 350 on the Internet. 30 
External email recipients can retrieve their graphical email 
using a standard Internet email client 360. The handwritten 
drawing can then be viewed as a file attachment using a GIF 
viewer such as a web browser. 

With reference to FIG. 3A, the process steps involved 35 
with sending a handwritten email message through a 
Domino Server and viewing it by the recipient are described 
in detail below: 

1. The Handwriting Java Client software is downloaded 
from the Handwriting Java Server to the client computer 40 
through a web page that is displayed in a web browser. 

2. The Handwriting Java Client software is initialized and 
establishes a connection to the handwriting Domino 
Server using the TCP/IP and remote method invocation 
(RMI) protocols. After initialization is complete, the 45 
Handwriting Java Client software displays a composition 
editor that is used to compose the handwritten message. 

3. The handwritten message is composed by the user select- 
ing the appropriate writing and drawing tools, colors, and 
styles. 50 

4. While the user is drawing, the pixel data representing the 
drawing is captured in the input data, area and stored in 
local memory. The user address€ss the email message to a 
recipient using Javascript fields on the web page in which 
the Handwriting Java Client is embedded. 55 

5. When the "Send*' command is issued, the Handwriting 
Java Client encodes the pixel data in base64 format. 

6. The Web page along with the encoded image is posted to 
the Domino Server using Javascript. 

7. An agent on the Domino Server decodes the image and 60 
creates an email message with an attached GIF file. 

8. The Domino server sends the email message with attach- 
ment to an external recipient's address via an SMTP 
(Simple Mail Transfer Protocol) gateway. 

9. The SMTP gateway transfers the email message to a mail 65 
server, which routes the message to the recipient's email 
box. 



,898 Bl 

8 

10a. an external recipient's e-mail client retrieves the email 
message with the GIF attachment from an Internet email 
server. 

10b. When the user (recipient of the email) opens the email 

containing the GIF attachment, the handwritten message 

in the attachment can be displayed using a GIF viewer. 
11a. If the recipient has an internal email address handled by 

a Domino Server, the server retrieves the email message 

with the GIF attachment, 
lib. The Domino Server sends the email message to the 

client computer as a web page when the client requests the 

page via their web browser email client. 
11c. The client's web browser email client displays the 

handwritten message as an image 
Handwriting Java Client and Real Time Server Version 

With reference to FIG. 4B, this version of the system uses 
the Handwriting Java CUcnt with a Real Time Handwriting 
Java Server. As before, the Handwriting Java Client 410(3 
operates in a web browser as a Java applet on the client 
computer 410, 430. The applet 41 Oa provides a drawing 
editor/viewer to compose and view handwritten messages. 
The applet 410a communicates with the Real Time Java 
Server component 420a on a server computer 420. The 
receiving Handwriting Java Client is notified when an email 
message for that user has been sent to the Real Time Java 
Server, and retrieves the email message firom the server. In 
this way, communication can take place using the Hand- 
writing Java Client in near real-time. This version is useful 
for users using mobile communication devices, such as 
PDAs, WAP-phones, etc. 

With reference to FIG. 4 A, the process steps involved 
with sending a handwritten message through a Real-Time 
Handwriting Java Server and and viewing it by the recipient 
are described in detail below: 

1. The client computer has a downloaded version of the 
Handwriting Java Client software, and establishes a con- 
nection with the server computer on which the Real Time 
Java Handwriting Server is running. 

2. The client computer identifies the user to the server by 
entering a user name and password. 

3. The server maintains a list of registered users, and a list 
of currently active users. When the client logs onto the 
server, the server looks up the user name and password in 
order to authenticate that person as a registered user, then 
the user is added to the list of active users. 

4. The client computer displays a list of active and inactive 
users which is downloaded from the server. 

5. The user clicks on a name from the list of active users to 
identify the user to whom they want to send a message. 

6. After the user selects a name fi*om the list of active users, 
the handwriting editor is displayed in the Handwriting 
Java Oient. 

7. The user creates a message by selecting the appropriate 
writing and drawing tools, colors, and styles. 

8. The Handwriting Java Client formats the message and 
stores it as pixel data until it is ready to be sent. 

9. The completed message is sent to the Real Time Java 
Handwriting Server in pixel format. 

10. The server receives the message and puts it into a 
repository where it can be retrieved by the user to whom 
it is addressed. 

11. All active client computers poll the repository on the 
server every five seconds to see if there are any messages 
for them. 

12. When the Handwriting Java Client on the recipient's 
computer discovers a message in the repository, the client 
computer requests the message from the server. 
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13. The server retrieves the message from the repository and 
sends it to the client computer of the recipient. 

14. The recipient's client computer displays the message in 
the Handwriting Java Client's drawing editorA'iewer. 

Handwriting Java Client and Internet Email Server Version 
With reference to FIG. 5, this version of the system uses 
the Handwriting Java Client along with a standard Internet 
email mail server. In this version, the Handwriting Java 
Client is installed as a plug-in to the client computer's web 
browser and operates as described before, and there is no 
Handwriting Java Server component. The Handwriting Java 
Client SlOa operates in a web browser as an installed Java 
applet on the client computer 510. The applet 510a provides 
a drawing editor/viewer to compose and view handwritten 
messages. The Handwriting Java Client formats the message 
and stores it as pixel data until it is ready to be sent. The 
message is addressed using Javascript fields on the Web 
browser form in which the Java applet is embedded. The 
pixel image is converted into a GIF file and attached to the 
email message. The Java applet 510i3 communicates with the 
Mail Server computer 540 either directly or through an 
SMTT gateway computer 520. The Mail Server 540 sends 
the email message with encapsulated GIF image directly to 
the recipient's client computer 530, and the recipient views 
the attached GIF file using whatever GIF viewer they have 
available on their computer. 

Handwriting Java Client and Wireless Internet Email Server 
Version 

With reference to FIG. 6, this version of the system uses 
the Handwriting Java Client along with a standard Internet 
email mail server providing email service to wireless client 
computers, such as WAP-phones and PDAs. As before, the 
Handwriting Java Client 610a operates in a web browser as 
an installed Java applet on the client computer 610. The 
email message is formatted with the handwritten image 
converted into an attached GIF file. The Java applet 610a 
communicates with the Mail Server computer 640 either 
directly or through an SMTP gateway computer 620, The 
Mail Server 640 includes a Wireless Application Protocol 
(WAP) interface which sends the email message with encap- 
sulated GIF image through a Wireless Service Provider 
having WAP handling capability to the recipient. 

The recipient's computer can be a thin client 630fl such as 
a digital cellphone with a WAP interface for receiving the 
email message via Internet and displaying the GIF file via its 
mini -web browser. Alternatively, the client computer may be 
a more robust, mobile client computer 630b such as a Palm 
Pilots or similar type of PDA, which has the memory and 
CPU capacity to have a Handwriting Java Client installed 
with its web browser and use it for composing and sending 
handwriting email messages as well as viewing them. The 
mobile client computer can then use the Handwriting Java 
Client to format the handwritten message as an attached GIF 
file (described in the Internet Email Server version) or as 
pixel data sent with the email for viewing by another client 
computer having a Handwriting Java Client running in its 
web browser (as described in the Real-Time Server version). 

A handwriting messaging application written for a palm- 
top or PDA device would currently have to be written in C 
or C++ because there are no current Java Virtual Machine 
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adaptations that can be used for such devices. However, 
several efforts are underway to create such Java VM mod- 
ules for palm-top and PDA devices. Using C/C++ to write 
full applications on palm-top devices has the current advan- 
tage that the security sandbox imposed on Java applets does 
not exist, thereby allowing a wider variety of messaging 
applications to be written, as long as actual implementations 
are kept simple (due to low CPU power and memory storage 
availability). The handwriting client can be kept simple by 
including only pen and eraser tools and dififerent line thick- 
nesses. Only palm-top devices with color displays would 
need a color palette; black and white palm-top devices 
would dither incoming messages to black and white while 
sending only two-color images. Since the client is written in 
C or C++, networking would be limited to standard TCP/IP 
communications instead of Java's RMI. For communica- 
tions through a proxy, packets can be wrapped in HTTP and 
sent through an HTTP proxy. If a handwriting server com- 
ponent is used with the palm-top devices, it would remain 
largely the same as described above, except that it would 
handle only standard TCP/IP communications, and would 
add the ability to receive messaging information wrapped in 
HTTP packets from behind a firewall. 

The functions of the module of the client component 
which converts and sends the handwritten message for 
handling as an email message depends upon the configura- 
tion of the system. If the system is configured with a Lotus 
Domino server on a Java VM platform, then the captured 
handwriting data is sent as a message to the Domino server 
in the form of a stream of pixel data which is converted by 
the server to a Graphics Interface Format (GIF) file and 
appended with an email header to form an email message 
handled by the server's email service. If the system is 
configured with a standard type of Internet email server, then 
the captured handwriting data can be converted at the client 
computer to a GIF file and sent as an email message to the 
Internet email server. If the system is configured for real 
time messaging between client devices, the client device can 
send the handwritten message as a GIF file appended to 
standard email, or send it as pixel data to a real-time 
messaging server which provides real-time messaging ser- 
vice between client devices. 

In FIG. 7 A, the user interface for the drawing editor/ 
viewer of the Handwriting Java Client is illustrated. For 
composing a handwritten message, the editor/viewer 710 
has a graphical data capture area 720 in which handwritten 
input can be entered with a touch pen or on a stylus pad and 
captured as pixel data. The editor/viewer 710 can offer a 
suite of standard types of drawing tools such as making line, 
circle, or polygon shapes and spraying and filling image 
areas. The graphical data capture area 720 is also the 
graphical image viewing area for email received with an 
attached GIF file or pixel data. In FIG. 7B, a typical layout 
for a PDA of the editor/viewer interface with drawing tools 
and color palette is illustrated. 

It is understood that many other modifications and varia- 
tions may be devised given the above description of the 
principles of the invention. It is intended that all such 
modifications and variations be considered as within the 
spirit and scope of this invention, as defined in the following 
claims. 



APPENDIX I 

GRAPHICS DATA CAPTURE & SENDING MODULE 



import java.io.*; 
import java.iitil.*; 
import javax.mai].*; 
import javax.activation.*; 
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GRAPHICS DATA CAPTURE & SENDING MODULE 



import javax.mail.iiitenieL*; 

r* 

* StarMailAgent is called as the form actioD for a starmail submission form 

* (sec, for example, pages/stormailmcssage) 

* Note that it is not a web query save agent! 
•/ 

public class StarMailAgent extends HttpAgentBase 

protected Session jn_,mailScssion; 

protected String m__strHost; 

protected String ni_strSMTP; 

protected String in_strUscr; 

protected Siring m_strPasswDrd; 

protected String m_strAdniin; 

protected boolean m^bFiltered; 

r' 

* Main emry point for this agent 



*^»**m**,*0mmmmmmm IS THE MAIN EMAIL DEU VERY CODE 

public void doPost(HttpAgcntRequest _req, HttpAgentRcsponsc _res) { 
/y Get mail parameters 
String protocol - "imap'*; 
n5_strHost - _iieq.getSeTvcrName( ); 
ni_strSMTP - _req.getParametcrCSMrPScrver''); 
m__strUser -= _req.getParameter(**From"); 
in_strPassvw>rd - _jeq.getParamctcr("Password"); 
m„strAdinin - _req.getParameter(" Admin'*); 
m__bFiltcrcd - _req.gctParameter("Filtered").cquals(**Yes"); 
// Establish mail properties and gel a session 
Properties props » new PTOperties( ); 
props.putCmail.imap.host" m_strHost); 
props.put("mail.sm^.host", m_strSMTP); 
m_mailSession - Session.getDefeulUnstanceCprops, null); 
// Gel mail params 

String strTo - _Teq.getParameter(*SendTo"); 
String strSubj - _req.getParamcter(*Subjcct"); 
String strBody - _Teq.geiParameteTCBody"): 
String strlmage - _Teq.gctParameter(**Imagc"); 
// create and send the message 
try { 

Message msg; 

if (strlmage — null) { 

// Create and send message, and append to the outbox 
msg - crcateMessagc(stiTo, strSubj, strBody); 

} else { 

msg - crcateImageMessage(strTo, strSubj, slrBody, strlmage); 
Transport.send(msg); 

if (_req.eetParameter("Save").equals("Yes")) { 
append Message(msg, **outbox"); 

} 

} catch (Messaging^ception e) ( 

_res^tContcntType(''tcxt/pl6in"); 
Print Writer out - _res.getWriter( ); 
out.print]n("Error!*'); 
ou t .p rin tln(m_strHost) ; 
e.printStadcTrace(ou t); 

} 

// Redirect to inbox 

String path -= _req.gctPathInfo( ); 

String shoftpath • path^ubstring(0, path-indexOfC-osP")); 
shortpath - shortpath.substmig(0, path,indexOf("/") + 1); 

_res,sendRedirect<8hortpath + _req.getParameter("MaUDB") + 

// 

"/Slnbox"): 

_res.sendRedirect(sbortpath + _req.gctParameter("urr'))j 

* Given some text, create a mail message out of it suitable for mailing 

* @param __to 

' @param _subj 

* @param text The message body text 

•/ . , 

protected Message creatcMcssagc(Stnng _lo, Strmg _subj, Strmg _text) 
throws MessagingException { 

Message msg - new MimeMessage(m_mailSession); 
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GRAPHICS DATA CAPTURE & SENDING MODULE 



[QtemetAddTCss fromAddr - createAddress (m_8trUser); 
msg^ctFrom (fromAddr); 

IntcnicLAddrcss[ } recip - new InteraetAddrcss[l}; 
String subject; 
if (iru_bFUtered) { 

recip[0] - creatcAddK:ss(in_strAdmm); 

subject - _subj + + _to; 

}clsc{ 

iccq3[0] - createAddTCSs(_U)); 
subject • _siibj; 

insg^etRecipients(Messagc.RecipientType.TO, recip); 
msg^etSubje ct(subject) ; 
insg^etContent(_text, "text/plain"); 
return msg; 

} 

r" 

* Given some text, create a mail message out of it suitable for mailing 

* @panim to 

" <^pai&m _subj 

* @pRTam _text The message body text 

* @p&Tam image The image data, enccxied as Base64 

V 

protected Message creaicInaageMcssagc(Striiig _to. String _subj. String _text. 
String __image) throws MessagingException { 

Message msg = new MimeMcssage(m„mailScssion); 
IntemetAddress fromAddr - createAddress (ni_strUscr); 
msg.s etFrom (fromAddr); 

Interne LAddress[ } recip — new InLemelAddress[l]; 
String subject; 
if (m_bFiltered) { 

TBcip[0] - createAddress(m_strAdmin); 

subject » _subj + + _to; 

} else { 

iecip[0] - createAddress(_to); 
subject - _subj; 

m5gJsctRecipicnts(Message.RecipicntType.T0, recip); 
msg^ctSkibj ect(subject) ; 
// Add the text pan 

Multipart mp - new MimcMult^3art( ); 
MimeBodyPart bodyl - new MimeBodyPajt( ); 
bodyl.setText(_text); 
mp.addBodyPart(bodyl); 
// Add the attachment 

MimeBodyPart body 2 » new MimcBodyPart( ); 

byte[ 3 data - Ba5e64Decoder.decodE( Liiiage.iDChaiArTay( )); 

bodyZsctDataHandler(new DataHandlerCdata. "image/giP^); 

body2.setFileNamc(-StarMail.gif'); 

n;^.addBodyPart<body2); 

msg^etContent(mp); 

retom msg; 

} 

' Create an internet address from this string. Basically searches for 
and appends 

* "@hostnamc" if not found 
*/ 

protected IntciuctAddress createAddress (String _addr) throws 
AddrcssExccption { 

if (_addr.indexO£("@'*) -= -1) 

_addr "@" + in__strHost; 
return new IntemetAddress (__addr); 

} 

/*• 

* Append the message to the given folder 

* @param _msg The mesage to append 

* @param _foldeT The folder to append the message to 
V 

protected void appendMessage(Message „msg. String _folder) throws 
MessagingException{ 

// Get a Store ohjeri 

Store store ■= m_:maiISession.getStore("imap"); 
store.connect(m_strHost, m_stiLIscr, m_strPas5word); 
// Open folder (or create it if it doesn't exist) 
Folder dfoldcr •= store .getFolder(_folder); 

if (idfoider.exists ( )) dfoldcrxreate (Folder. H01X)S_MESS AGES); 
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GRAPHICS DATA CAPTURE & SENDING MODULE 



Message[ ] insgs- { _insg }; 
dfolder.appendMessag6s(insg5) ; 
dfoIder.close(&lse); 
store.close( ); 

} 

} 



I claim: 

1. An electronic messaging system comprising: 

(a) a server component operable on a server computer on 
a network with an email host server for receiving an 
email message sent from a user and storing it for 
retrieval by a user to whom it is addressed, 

(b) a remote client computer connectable to the server 
computer through an online data connection to the 
network, and an email client software operable on the 
remote client computer for setting up an email client 
interface for the user to set up and send email to a 
recipient via the email host server on the server com- 
puter; and 

(c) a client component operable with the email client on 25 
the cUenl computer connected to the network for setting 
up a graphical data capture area in the client computers 
email client interface, said client component also 
including a graphical input device which is operatively 
coupled to the graphical data capture area set up in the 30 
email client interface for allowing the user to enter 
handwritten or handdrawn input through the graphicai 
input device, and for capturing the handwritten or 
handdrawn input as graphical data through the email 
client and sending it via the network to the server 35 
component for handling as an email message. 

2. An electronic messaging system according to claim 1, 
wherein the client component is operable for setting up a 
graphical data viewing area in the client computer's email 
client interface for viewing a handwritten or handdrawn 40 
email message received from the email host server of the 
server computer. 

3. An electronic messaging system according to claim 1, 
wherein the client component is a Java applet downloadable 

to the client computer's email client interface through a 45 
standard web browser on the client computer. 

4. An electronic messaging system according to claim 1, 
wherein the client component is a Java applet installed in the 
client computer's email client interface in a standard web 
browser on the client computer 50 

5. An electronic messaging system according to claim 1, 
wherein the client component captures the graphical data as 
pixel data and sends it with the email message to the server 
component, and the server component encodes the pixel data 
and formats it as a graphics file for attachment to the email 55 
message. 

6. An elearonic messaging system according to claim 5, 
wherein the server component is a handwriting Java server 
operating on the server computer and sends the email 
message with pixel data to a client computer having a similar 60 
client component for viewing the pixel data as a correspond- 
ing handwritten or handdrawn image. 

7. An electronic messaging system according to claim 5, 
wherein the server component is a handwriting Java server 
operating on the server computer and converts the pixel data 65 
to a graphics file that is attached to the email message and 
sends it to an external SMTP gateway or Internet mail server. 



8. An electronic messaging system according to claim 1, 
wherein the client component captures the graphical data 
and converts it to a graphics file that is sent with the email 
message to the server component, and the server component 
handles the ema0 message as standard email with an 
attached graphics file. 

9. An electronic messaging system according to claim S, 
wherein the server component is a handwriting Java server 
operating on the server computer and sends the email 
message with attached graphics file to a client computer 
having a similar client component for viewing the graphics 
file as a corresponding handwritten or handdrawn image. 

10. An electronic messaging system according to claim 8, 
wherein the server component is a handwriting Java server 
operating on the server computer and sends the email 
message with attached graphics file to an external SMTP 
gateway or Internet mail server 

11. An electronic messaging system according to claim 1, 
wherein the client component captures the graphical data as 
pixel data and encodes it as a message for sending to the 
server component, and the server component formats the 
message as an email message with an attached graphics file. 

12. An electronic messaging system according to claim 1, 
wherein the client component captures the graphical data as 
pixel data and sends it with the email message to the server 
component, and the server component sends the email 
message with the pixel data to a client conaputer having a 
similar client component for viewing the pixel data as a 
corresponding handwritten or handdrawn image. 

13. An electronic messaging method comprising: 

(a) providing a graphical data capture area in an email 
client interface operable on a client computer having an 
online connection to a network; 

(b) providing a graphical input device operatively coupled 
to the graphical data capture area set up in the email 
client interface; 

(c) composing an handwritten or handdrawn email mes- 
sage in the graphical data capture area through the 
graphical input device, and capturing the handwritten 
or handdrawn input as graphical data through the email 
client and sending it as an email message via the 
network to a server component operable on a server 
computer; and 

(d) receiving the email message via the server component 
and storing it for retrieval by a user to whom it is 
addressed. 

14. An electronic messaging device comprising; 

a handwriting messaging component operable in an email 
client interface of a computer connected on a network, 
wherein said handwriting messaging component sets 
up a graphical data capture area in the email client 
interface into which a user can enter handwritten or 
handdrawn input, 

a graphical input device which is operatively coupled to 
the graphical data capture area set up in the email client 
interface, and 
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wherein said handwriting messaging component captures 
the handwritten or handdrawn input as graphical data 
and sends it as an email message on the network. 

15. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component converts the 5 
graphical data to a graphics file thai is attached to the email - 
message, 

16. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component formats the 
graphical data as pixel data and send it with the email lO 
message. 

17. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component is operable 
for setting up a graphical data viewing area for viewing 
graphical data sent with an email message as a correspond- 15 
ing graphical image, 

18. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component is operable 
on a personal digital assistant or palm-top device for receiv- 
ing graphical email via a wireless connection on the network 20 
and viewing the graphical data sent with an email message 

as a corresponding graphical image. 
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19. An electronic messaging device according to claim 14, 
wherein the handwriting messaging component sets up the 
graphical data capture area through a Java applet operable 
with an email client installed on the device. 

20. A method of electronic messaging comprising: 
providing a handwriting messaging component operable 

with an email chent interface on a device connected to 
a network; 

setting up via the handwriting messaging component a 
graphical data capture area in the email client interface 
into which a user can enter handwritten or handdrawn 
input through a suitable graphical input device; 

providing a graphical input device which is operaiively 
coupled to the graphical data capture area set up in the 
email client interface; and 

capturing the handwritten or handdrawn input as graphi- 
cal data through the email client and sending it as an 
email message on the network. 
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devices specified in a user profile within the Information 
Management Network. 
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INFORMATION MANAGEMENT NETWORK 
FOR AUTOMATED DELIVERY OF ALARM 
NOTIFICATIONS AND OTHER 
INFORMATION 

PRIORITY 

This application claims priority firom U.S. Provisional 
/^plications Sen No. 60/166,585, filed Nov. 19, 1999, and 
Sen No. 60/232,340, filed Sep. 14, 2000, and incorporates 
both by reference herein as though fully set forth herein. 

FIELD OF THE INVENTION 

This invention relates generally to security and monitor- 
ing systems for both residential as well as business and 
industrial use. It relates more particularly to security and 
monitoring systems that operate over wired or wireless 
networks. Even more particularly, it relates to security and 
information systems that use condition sensors connected by 
a network that facilitates remote monitoring, notification, 
and interaction. 

BACKGROUND OF THE INVENTION 

Existing premises security monitoring systems are usually 
connected to central monitoring stations via the public 
switched telephone network (PSTN) or a by a commercial 
wireless network. In the event of a system alert, current 
monitoring center procedures provide the customer with an 
alarm verification call, notification to the local police or fire 
authorities, and notification to a number of designated 
contact numbers. Although only 20% of the households in 
this coxmlry have monitored security systems, false-alarm 
pohce dispatches account for 98% of police dispatches 
nationwide. Such false alarm events typically cost munici- 
palities nationwide over $1.5 billion per year. As a result of 
the high incidence of false alarms plaguing the industry, it is 
not uncommon for the police to take as long as an hour to 
reach the premises where an alarm has been activated. 

Further, when an alarm system is violated, the siren only 
sounds for a period of up to five minutes. Should the 
homeowner return to the premises before the police arrive 
and after the alarm ceases, the safely of that individual is 
seriously compromised. 

In the residential security system industry today, upon the 
receipt of an alarm transmission from a security or premises 
monitoring system, the dispatcher of the central station 
monitoring facility calls the premises to verify whether the 
emergency event is valid. If there is no answer or if it is 
otherwise deemed necessary, the dispatcher notifies the 
appropriate authority for emergency dispatch. At the time of 
emergency notification, the dispatcher at the central station 
monitoring facility is limited to the information transmitted 
from the base unit in the premises. The dispatcher does not 
have access to real-time information about the situation that 
could influence his decision as to whether to notify the 
emergency authority. 

Furthermore, the calls made to the customer contacts after 
the authorities are dispatched are most typically not given 
priority by the central station monitoring facilities and are 
only made to the customer contacts when emergency calls 
and dispatches for other customers are not being made. 
Therefore, it is not uncommon for the contacts listed in the 
customer file to be notified about the alarm so long after the 
incident that notification is useless. 

When the central station monitoring facility calls the 
premises to verify the alarm event, if the event notification 
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is not cancelled, the dispatcher immediately notifies the 
emergency authorities for dispatch to the premises in ques- 
tion. If the homeowner is not at home at the time of the alarm 
event, the homeowner's knowledge of the premises, hard- 
ware and authorized users is not available to iofiuence or 
control the action taken by the central station monitoring 
facility at the time of alarm signal transmission. And, it is 
only after the emergency authorities have been dispatched 
that the dispatcher of the central station monitoring facility 
attempts to notify the other contacts Listed in the customer's 
file. 

Current systems also allow customers limited or no 
opportunities to alter contact numbers in their profiles or to 
be contacted via the growing variety of communication 
devices available to the public (e.g., fax, e-mail, pager. 
Personal Digital Assistant (PDA), text messaging device). It 
is therefore generally uncommon for the contact numbers 
stored in the customer's contact fist to be up-to-date due to 
the cumbersome process required to update a contact Hst. 

TTiese factors seriously compromise the safety of the 
owner of the premises, who, if not on premises at the time 
of the alarm event, may not receive information about the 
alarm notification prior to entering the premises while an 
intruder is still present. The above factors also contribute to 
the high incidence of false alarm dispatches in this country. 
If the owner of the premises is not on the premises at the 
time of the alarm event, the owner is not able to direct the 
central station monitoring facility whether to cancel or 
continue with authority dispatch. 

The current call flow process from a security or premises 
monitoring system direct to a Central Monitoring Station, 
which calls the premises for verification and then notifies the 
authority for emergency dispatch, is an inefficient premises 
monitoring solution. This call flow configuration also has 
adverse cost and safety implications for the system owner, 
central station monitoring facilities, authorities, and cities 
ahke. 

It is therefore an object of the invention to provide an 
improved system for monitoring premises security and other 
conditions. It is a primary object of this invention to provide 
a system that transmits interactive notifications about pre- 
mises event and alert information in the order and manner 
determined by the customer within the customer profile to 
any wired or wireless communication device. It is yet a 
further object of this invention to receive transmissions of 
alarm notifications regarding changes in the status of any 
one of a number of sensors or parameters in a security or 
premises monitoring system at a remote Information Man- 
agement Network via the Public Switched Telephone 
Network, Wireless Commercial Network, cable network or 
other commercial network. 

It is another object of the present invention that the 
customer be able to remotely and securely access the Infor- 
mation Management Network via the Internet or telephone 
to modify and review the information in his Customer 
Profile and Event Log within the Information Management 
Network, using a secure web or telephone interface, to easily 
and securely maintain and update contact lists and notifica- 
tion preference points, schedule dmes for certain informa- 
tion notifications, update call flow sequences, access per- 
sonal account information, review detailed alarm history, 
review results of notifications made to each of the delineated 
devices, review billing information, schedule non-alarm 
event notifications and update and review other alarm signal 
and hardware related information. It is another object of the 
invention that the Information Management Network initiate 
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periodic interactive notifications to customers to encourage 
them to update their Customer Profile by entering the correct 
digital or voice recognized pass code. 

It is yet a fiirther object of the invention that the customer 
be able to determine the order in which contacts will receive 
the event transmission and have the opportunity to cancel 
said event transmission prior to said transmission being sent 
to the central station monitoring facility or private guard 
service for authority dispatch. It is another object of the 
present invention that an authorized recipient of an event 
notification can cancel the transmission of the notification to 
the subsequent contacts in the notification sequence or a 
central station by entering the correct digital or voice 
recognized pass code. It is yet another object of this inven- 
tion that a central station monitoring facility use the Infor- 
mation Management Network to contact customer devices 
listed in the Customer Profile concurrently or following the 
dispatcher's verification call to the home, to allow an 
authorized individual* remote from the premises, to cancel 
the alarm notification prior to dispatch of the authorities. It 
is still another object of the invention that the recipient of a 
notification call be able to be transferred or conferenced with 
the emergency authority through a digital or voice request. 
It is another object of the invention that the receipt of 
information by the recipient can be confirmed and a record 
kept in the event log database of the Information Manage- 
ment Network for retrieval and review at a later date by an 
authorized individual. It is another object of the invention 
that the Information Management Network complement or 
replace the functions of a central station monitoring facility. 

SUMMARY OF THE INVENTION 

The system of the current invention provides to users and 
central station monitoring facilities an efficient and afford- 
able event notification solution in which the call flow 
configuration of the invention is designed to enhance the 
safety and convenience of the customer and reduce the 
incidence of police, fire, or other emergency dispatches 
generated by false alarms. The invention comprises a secure 
interactive and remotely accessible Information Manage- 
ment Network (IMN) based routing system for alert, 
medical, and other emergency event information. The sys- 
tem delivers sequential interactive event notifications based 
on signals received from sensors at the monitored premises 
and sends them in text, voice, DTMF or digital, text 
messaging, or other formats to a plurality of remote wired 
and wireless devices, including cell phone, pager, email, 
SMS, landline phone, text messaging device, personal digi- 
tal assistant, and fax as appropriate. The IMN further deliv- 
ers such notifications to a pre -designated centra] station 
monitoring facility in security industry format. 

The hardware of the IMN is a combination of a plurality 
of modems, an alarm monitoring engine, at least one server 
containing customer information databases, a unified mes- 
saging platform, event logs, web and telephony interfaces, 
an interactive messaging server, a Private Branch Exchange/ 
Interactive Voice Response (PBX/IVR) interface, and a 
telephone conferencing switching mechanism. This configu- 
ration translates the data received from a premises hardware 
unit into a notification capable of being sent in voice or text 
format to any number of customer designated devices 
including telephone, fax, email addresses, pager. Personal 
Digital Assistant (PDA), or text messaging device. The 
systems are redundant. 

The IMN routing system is domiciled at a secure inde- 
pendent hosting facihty or at a secure central station moni- 



',478 Bl 

4 

toring facility. The system is able to receive event and alert 
information from any security or premises monitoring 
devices and sequentially transmit interactive notifications 
about the event and alert to wired and wireless commimi- 
5 cations devices specified in the Customer's Profile within 
the IMN. Transmissions can be made in voice, text, DTMF, 
digital, text messaging or other formats to such devices as 
cell phone, pager, email, fax, text message device and SMS, 
as well as in Contact ID, SIA, or other security industry 
10 formats to an independent central station monitoring facility 
for them in turn to dispatch the authorities. 

The automated secure remote IMN has a novel interactive 
alarm notification call flow sequence that uses information 
stored in the Customer Profile within the database of the 
15 IMN to notify designated points of contact by making 
sequential interactive notifications to one or more persons or 
locations previously designated in the Customer Profile over 
one or more wired and wireless devices in text, voice, 
DT^S, text messaging or digital formats to notify them of 
20 an emergency event or a change in the status of any premises 
sensors. Delivery to any of the above destinations occurs in 
the order and manner specified in the authorized user's 
Customer Profile within the IMN. 

For an alarm notification, the information conveyed can 
include the customer name, address, location of the security 
or premises hardware, phone number of the security or 
premises hardware, date, time, type and name of sensor, 
zone, local emergency authority phone number, and other 
relevant personal or premises-related information. The IMN 
also allows for a two-way communication interface with the 
security or premises hardware. 

The IMN, having automatically received an alert notifi- 
cation from the premises where the monitoring devices are 
located, automatically accesses a data base, finds the par- 
ticular owner's profile, and then also automatically sends 
interactive alert messages to phones, faxes, email devices, 
pagers, hand-held computers and/or a manned monitoring 
center as previously specified by the owner. The use of the 
alarm system is electronically logged in the IMN so that it 
can be reviewed later. 

The system uses the information populated within the 
Customer Profile to instantly alert the customer and his 
contacts of the alarm event, for example, to warm them of 
45 an intruder on the premises or to alert them to another type 
of emergency event at the premises and enable them to make 
a decision as to whether the emergency authorities should be 
notified by the customer directly or through a central station 
monitoring facility or guard service, or the event notification 
5Q should be cancelled. 

The user can securely access the IMN via the Internet or 
telephone to program or re-program the user's customer 
profile, to include notification preference points, ordering of 
notifications, routing paths for different types of 
55 notifications, times for notification and other related infor- 
mation. This access is to a single universal a«;ess point. 
Receipt of information by the user can be confirmed and a 
record kept in the event log database of the IMN for retrieval 
at a later date by an authorized user. 
60 The IMN also permits the iiser to modify the pre-existing 
premises alarm notification call flow sequence by allowing 
the user to direct and manage the alarm notification process. 
Event notifications from the IMN are interactive and made 
sequentially to the contacts designated in the Customer's 
65 Profile, allowing the recipient of the event notification to 
determine the next action to be taken by the IMN in the call 
flow sequence. Authorized recipients are able to terminate or 
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redirect subsequent event notifications by entering the cor- 
rect pass codes digitally or through voice recognition tech- 
nology. 

Customers can select the number and ordering of contacts 
to be notified and queried prior to alarm event transmissions 
being sent to the central station monitoring facility for 
emergency authority dispatch. Customers can select to have 
a central station monitoring facility as part of the call flow 
sequence, or have notifications sent only to the contacts 
listed in their profile for those contacts to notify emergency 
authority for dispatch. Authorized users can access their 
Customer Profile via a pass code encrypted telephone or 
Internet interface, to change alarm system configuration, 
update their points of contact, establish the order in which 
contacts will be notified based on the type of alarm event and 
review emergency information any time they desired. Using 
the pass code accessible Internet and telephone interfaces, 
users can access information about their accounts, including 
billing information, contact points, pass code information 
and alarm history. The invention also provides for externally 
specified and changeable control of alarm system operation 
and home automation devices via the IMN or fi-om a remote 
telephone. Externally directed control of alarm system 
operation and home automation devices takes place via the 
IMN. 

The ability to securely and easily update contact infor- 
mation at anytime and firom anywhere allows the customer 
to be part of and closely manage the security notification call 
flow process and enhance his safety by directing alarm event 
notifications to contact him on specified devices early on in 
the event notification process. This feature, coupled with the 
user's ability to cancel an alarm notification prior to its being 
sent to the central station monitoring facility, influences the 
call flow sequence of alarm event information and reduces 
the incidence of false alarm dispatches. Authorized contact 
recipients are identified with user-determined pass codes, 
verified by a digital pin number or Voice Recognition pin 
number, prior to that person instructing the IMN as to the 
next step or steps of action to be taken in the call sequence. 
Another important feature is the logging of event notifica- 
tion information into the database of the IMN so that the 
customer can review it at a later dale. 

In this system users have direct, seciu"e access to the 
monitoring network database via phone or the global com- 
puter network in order to review and change alarm system 
configuration, points of contact and emergency information 
any time they desire. Customers have access to securely 
manipulate their personal information within their Customer 
Profile over the telephone or through a web interface, 24 
hours a day. 

Customers can elect to have central station monitoring 
facility back-up capability to be employed after one or more 
contacts Listed in the Customer's Profile have been contacted 
and queried, and have failed to receive or respond correctly 
to the interrogation from the IMN. Customers can also elect 
not to have a central station monitoring facility as part of the 
call flow sequence and have the notifications sent only to the 
contacts listed in their Customer Profile. In all notification 
calls, customers are provided the opportunity to be trans- 
ferred directly to the emergency authority for them to initiate 
a dispatch to the premises. 

In certain instances, customers can select to have a central 
station monitoring facihty or guard service notified for 
police or emergency dispatch, after one or more of the 
contacts listed in the Customer Profile have received the 
information and have either failed to properly cancel the 



event notification or have proactively instructed the IMN to 
contact the central station monitoring facility or guard 
service for dispatch. At the same time, recipients of alarm 
and event notifications are provided the local police number, 

5 as well as the ability to be transferred or conferenced with 
the local police or emergency authority. 

Through the IMN, customers can also subscribe to receive 
notifications with content not related to the security or 
premises hardware. Such notifications include medication 

10 reminders, homeland security notifications and news events, 
transmitted at specific times, on specific dates, or under 
specific circumstances, and transmitted to a plurafily of 
wired and wireless devices in text and voice formats as 
designated in the customer profile. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

1. FIG. 1 is a diagram of the communication flow estab- 
lished by the Information Management Network. 
20 2. FIG- 2 is a diagram of the communication established 
by the Information Management Network including the 
central station monitoring facility or private guard service, 
the police, or other emergency authority, 

3. FIG. 3 is a schematic diagram depicting the hardware 
25 components of the Information Management Network and 

the communications portals into and out of the Information 
Management Network. 

4. FTG. 4 is a flow diagram illustrating the work flow 
process within the Information Management Network. 

30 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A Security or Premises Monitoring System has been 
previously described in the parent application, which has 
been incorporated by reference. The Seciu-ity or Premises 
Monitoring System is connected by a communications 
circuit, which can be any of or a combination of elements 
selected from the public switched telephone network, a 
wireless network, digital subscriber line via modem, cable 
modem connected to a cable network, the internet, and any 
other communications network capable of transmitting dual 
tone multiple frequency tones or their equivalent- The Secu- 
rity or Premises Monitoring System connects on demand to 
the Information Monitoring Network (IMN) of this 
invention, described below. 

With respect to hardware, the IMN comprises at least a 
DTMF modem, an application interface, at least one server 
containing customer information databases, a unified mes- 
50 saging platform, an event log, a web interface, and a 
telephony interchange, such as a Private Branch Exchange/ 
Interactive Voice Response (PBX/IVR) interface. (See HG. 
3). The at least one server comprises a server type computer 
the nature and configuration of which is well known to those 
55 skilled in the art. Those skilled in the art will also recognize 
that the network of this invention can be implemented with 
a variety of computing and communications hardware dif- 
fering from those expficitly disclosed in this application but 
well known to those skilled in the art. 
60 The hardware and software configuration translates tbe 
DTMF tones received from the Security or Premises Moni- 
toring System into a message capable of being sent in voice 
or text format. As the following will describe, the IMN 
enables sending the message to any number of customer 
65 designated devices including telephone, fax, email 
addresses, pager, or Personal Digital Assistant (PDA) such 
as a PALM PILOT 
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Referring to FIG. 1, alarm or event information is sent 
from the Security or Premises Monitoring System 1 to the 
remote Information Management Network 2 via any type of 
communication channel. The system retrieves user informa- 
tion and alert notification addresses (including but not 5 
limited to phone numbers, fax numbers email addresses, 
pager numbers, and Personal Digital Assistant device 
addresses) from the customer database and, as described in 
more detail below, forwards the alarm notification or medi- 
cal information to the designated points of contact, simxil- jq 
taoeously or sequentially. For an alarm notification, the 
information conveyed includes the customer name, location 
of the base unit, phone nimaber of base unit, date, time, type 
of sensor and zone. 

Interactive notifications are then sent from the Informa- 15 
tion Management Network to the contacts listed in the 
Customer Profile 17 (shown in FIG. 3) via at least one 
commxmication device, including cell phone, pager, email, 
SMS, landiine phone, fax or text messaging device. Contact 
recipients of the interactive alert notifications are provided 20 
the option to cancel the event notification by providing a 
correct pass code using digital entry or voice recognition 
technology; send the alert notification to the next contact in 
the Customer Profile 17, or be transferred to or conferenced 
with the local emergency authority. There is no central 25 
station monitoring facility associated with the call flow 
sequence of FIG. 1. 

Referring to FIG. 2, alarm or event information is sent 
from the Security or Premises Monitoring System 1 to the 
remote Information Management Network 2 via any com- 30 
munication channel including the Public Switched Tele- 
phone Network, the Internet, Cable or a Wireless Network. 
Interactive notifications are then sent to the contacts by the 
Information Management Network listed in the Customer 
Profile 17 (shown in FIG. 3) via any number of communi- 35 
cation devices including cell phone, pager, email, SMS, 
landiine phone, fax or text messaging device. Contact recipi- 
ents of the interactive alert notification are provided the 
option to: cancel the event notification by providing the 
correct pass code using digital or voice recognition technol- 40 
ogy; send the alert notification to the next contact in the 
Customer Profile 17; send the alert notification to the central 
station monitoring facility. In this configuration, the central 
monitoring station is generally responsible for police and 
emergency authority notification for dispatch, but optionally 45 
the responder can be transferred to or conferenced with the 
local emergency authority. 

Referring to FIG. 3, information sent from the Security or 
Premises Monitoring System 1 to the Information Manage- 
ment Network 2 enters the Information Management Net- 50 
work 2 through the Telephony Server 11, Cable Modem 12 
or IP Server 14. Alarm information then flows through the 
Alarm Monitoring Engine 15 to the Database Server 16. 
Information regarding the specific account is stored in the 
Customer Profile 17 within the Database Server 16 that 55 
provides the work flow process for each alarm event. All 
alarm notification events are sent by the Interactive Mes- 
saging Server 18 to the customer contacts via landiine 
phone, cell phone, text messaging device, pager, email, fax 
or SMS. The Interactive Messaging Server 18 can interro- 60 
gate the contact recipient of the alarm notification for 
information and institute the appropriate work flow process 
based on the response of that contact. The results of all work 
flow processes are stored the Event Log 19 and can be 
reviewed by authorized individuals through the Telephony 65 
Interface into the Telephony Server 11 or the Web Interface 
through the Web Server 20. During a notification, customers 
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are provided the option to be connected to the police phone 
number listed in their Customer Profile 17 within the Data- 
base Server 16. This connection is made through the Tele- 
phone Conference Switching Mechanism 21. Alarm notifi- 
cations associated with central station monitored accounts 
are transmitted from the Database Server 16 to the central 
station monitoring facility via the Interactive Messaging 
Server 18 following the call flow sequence designated in the 
Customer Profile 17. Access to the Customer Profile 17 and 
changes to said Customer Profile 17 are made through the 
Telephony Server 11, Customer Service Receiver 22 and 
Web Server 20 into the Information Management Network 
2. 

Referring to FIG. 4, the call flow processes are detailed 
for an alarm event. When the incoming signal is received by 
the Information Management Network 2, the signal enters 
the Alarm Monitoring Engine 15 and is immediately logged 
into the Event Log 19 within the Database Server 16. The 
alarm notification string is parsed to determine information 
about the account. Using the customer identification 
number, the Customer Profile 17 within the Database Server 
16 is queried for the alarm type and customer account 
information for the work flow processes. 

For a central station monitored account, there are different 
workflows associated with non-critical, critical, panic, and 
fire events. In the event of a non-critical alarm, which 
represents a low battery event, AC Power loss or other 
non-criticai event, the alarm event information is sent by the 
Notification Engine 23 within the Interactive Messaging 
Server 18 to the customer's non-critical contact on the 
device specified in the Customer's Profile 17. The results of 
this notification are stored in the Event Log 19 within the 
Database Server 16. In the event of a critical alarm, the 
information is sent to the customer's first contact using the 
Notification Engine 23 within the interactive Messaging 
Server 18. The contact is given the option to cancel the alarm 
or send the signal to the central station rnonitoring facility 8 
for dispatch. 

If the contact request's that the central station monitoring 
facility 8 be notified for the dispatch of the authorities, the 
Notification Engine within the Interactive Messaging Server 
18 sends the alarm transmission to the central monitoring 
station 8 for authority dispatch and the results of the work 
flow process are stored in the Event Log 19. All other 
contacts listed in the Customer's Profile 17 are then notified 
that alarm event notification was sent to the central station 
monitoring facility 8. 

If the alarm notification information is sent to a device 
where the contact chooses to cancel the alarm event, the 
customer's notification cancel code is requested. If the 
correct alarm notification cancel code is entered, the alarm 
notification event and work flow process are cancelled and 
the information of the work flow process is stored in the 
Event Log 19. 

If the incorrect alarm notification cancel code is entered, 
the customer is requested to re-enter the code. If an invalid 
alarm notification cancel code is entered second time, or no 
code is entered, the work flow process moves to the next 
contact listed in the Customer's Profile 17 and the notifica- 
tion process is repeated. When the second contact is notified, 
if there is no answer, an invalid cancellation code is entered 
or the contact selects to have the central station monitoring 
facility 8 notified, the alarm event is sent to the central 
station monitoring facility 8 for authority dispatch and the 
information is stored in the Event Log 1 9. In any case where 
a valid alarm notification cancel code is entered, the noli- 
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fication event and the workflow process are cancelled, and 
the information regarding the cancellation of the alarm event 
notification is stored in the Event Log 19. In any case where 
the central station monitoring facility 8 is notified for 
dispatch, all remaining contacts are notified that the alarm 5 
event was sent to the central station monitoring facility 8 and 
the information is then stored in the Event Log 19. When an 
alarm notification is sent, if the notification is unable to be 
delivered by the Information Management Network 2, if the 
line is busy or there is no answer by the first contact listed lO 
in the Customer Profile 17, the workflow process moves to 
the next contact listed in the Customer Profile 17. 

If the first contact is answered by a voice mail or answer- 
ing machine, the Notification Engine 23 within the Interac- 
tive Messaging Server 18 recognizes that it is not a live 
person, leaves a message and the work flow process moves 
to the next contact listed in the Customer's Profile 17. If the 
next contact is not answered, is answered by a voice mail or 
answering machine, or is answered and the correct alarm 
notification cancel code is not entered, the Notification 20 
Engine 23 within the Interactive Messaging Server 18 leaves 
a message where applicable and the alarm event notification 
is sent to the central station monitoring facility 8 and the 
remaining contacts listed in the Customer Profile 17 are 
notified that alarm event was sent to the central station 25 
monitoring facility 8. This information is then stored in the 
Event Log 19 within the Database Server 16. 

In the event of a fire or panic alarm event, the information 
is sent directly to the central station monitoring facility 8 and 
all of the customer contacts listed in the Customer Profile 17 
are notified of the alarm event. The information is stored in 
the Event Log 19. There are no cancellation privileges 
associated with these events. 

For an account that does not have central station 
monitoring, there are different workflows associated with 
non-critical, critical, panic, and fire events. In the event of a 
noncrilical alarm, which represents a low battery event, AC 
Power loss, or other non-critical event, the information is 
sent to the customer's non-critical contact on the specified 
device, using the Notification Engine 23 within the Interac- 
tive Messaging Server 18. The results of this notification are 
stored in the Event Log 19 within the Database 16. 

In the event of a critical alarm, the information is sent to 
the customer's first contact using the Notification Engine 45 
within the Interactive Messaging Server 18. The contact is 
given the option to cancel the alarm event or send the signal 
to the next contact listed in the Customer's Profile 17. 

If the contact chooses to cancel the alarm event, the 
customer's notification cancel code is requested. If the 50 
correct alarm notification cancel code is entered, the alarm 
notification event and work flow process are cancelled and 
the results of the work flow process are stored in the Event 
Log 19. If the incorrect alarm notification cancel code is 
entered, the customer is requested to re-enter the alarm 55 
notification cancel code. If an invalid alarm notification 
cancel code is entered a second time, or no alarm cancella- 
tion code is entered, the work flow process moves to the next 
contact listed in the Customer's Profile 17 and the process is 
repeated. This work flow process will continue through all of 60 
the customer contacts until the alarm event is cancelled 
using the correct alarm notification cancel code. TOth each 
notification, the contact is given the information about the 
alarm event, including the name, address and system zone 
activated, as well as the police phone number to contact in 
the event of an emergency. During the process, the contact 
is given the option to have the notification sent to the next 
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contact listed in the Customer Profile 17; given the option to 
cancel the notification; or be connected directly to the police 
phone number listed in his Customer Profile 17. In any case 
when a valid alarm notification cancel code is entered, the 
notification event and the workflow process are canceUed 
and the information is stored in the Event Log 19 within the 
Database Server 16. When an alarm notification is sent, if 
the line is busy or there is no answer by the first contact 
listed in the Customer Profile 17, the workflow process 
moves to the next contact listed in the Customer's Profile 17 
to continue the work flow process. 

In the same event, if the notification is answered by a 
voice mail or answering machine, the Notification Engine 18 
recognizes that it is not a live person, leaves a message and 
the work flow process moves to the next contact listed in the 
Customer's Profile 17. If the next contact is busy, not 
answered, answered by a voice mail or answering machine, 
or answered and the correct alarm notification cancel code is 
not entered, the Notification Engine 18, leaves a meissage 
where applicable and moves to the next contact listed in the 
Customer's Profile 17. This process continues through all of 
the contacts listed in the Customer's Profile 17 until the 
correct alarm notification cancel code is entered to cancel 
the work flow process. 

After the work flow process has attempted contact v^ath all 
devices listed in the Customer's Profile 17, the Notification 
Engine 23 within the Interactive Messaging server 18 will 
try to send the alarm notification to those devices that were 
busy or where there was no answer to attempt to deliver the 
alarm event notification information. 

In the event of a fire or panic alarm event, all of the 
customer contacts listed in the Customer Profile 17 are 
notified of the event and the results of the notification are 
stored in the Event Log 19 within the Database Server 16, 
There are no cancellation privDeges associated with these 
events. 

Confirmation that the alarm notification has been success- 
fully transmitted to the customer's designated dcvic6(s) is 
boused in the event log and also in the Security or Premises 
Monitoring System. In a preferred embodiment, the IMN 
allows for a two-way communication interface with the base 
unit. In this way, the present invention allows for remote 
activation or resetting of the alarm and other devices in the 
home for security and home automation purposes, through 
the initiation of a phone call or global computer network 
transmission to the IMN. The IMN also allows the customer 
to preprogram alarm and home automation functions to 
initiate specific processes at specified times of the day. 

The Information Management Network 2 can be pro- 
grammed to forward certain alarm event transmissions 
directly to the central station monitoring facflity 8 while 
other event transmissions are sent to the central station 
monitoring facility 8 only after the first, second, third or 
fourth transmission to the contacts listed in the Customer 
Profile 17. 

Referring to FIG. 3 again, the account information in the 
Customer Profile 17 within the Information Management 
Network 2 can be populated by the customer or other 
authorized individual via a secure web interface on the Web 
Server 20 or via a secure telephone interface using the 
Telephony Server 11. To access their Customer Profile 17, 
customers are required to provide their personal user name 
and a unique personal pass code. Through these interfaces, 
authorized individuals can customize their personal account 
information to add, delete or modify their pre -designated 
contacts and designate the order of alarm event information 
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transmissions lo their contacts, modify their home address, 
phone number, police contact number, and billing informa- 
tion. Any change made to data within the Customer Profile 
17 is automatically sent via PSTN or Internet interface to the 
central station monitoring facility S to update the customer's 
account information on a real time basis. This transfer of 
information applies only to those customers subscribing to 
central station monitoring services, which services serve as 
a complement to the alarm notification call flow process 
made by the Information Management Network 2. 
What is claimed is: 

1. An information management network system for rout- 
ing information to one or more recipients, said network 
system comprising: 

a) means for receiving information from a monitoring 
system; 

b) one or more user profiles, each of the one or more user 
profiles comprising one or more specified notification 
contact data entries and a specified notification contact 
flow sequence; 

c) means for selecting a single user profile corresponding 
to the monitoring system and for retrieving the selected 
single user profile; 

d) means for extracting from the selected single user 
profile the one or more specified notification contact 
data entries and the specified notification contact flow 
sequence; 

e) means for identifying from each of the one or more 
notification contact data entries one or more commu- 
nication receiving devices and for each such device a 
device-specific format, each of said communication 
receiving devices being configured both to receive 
messages in device-specific formats and to transmit a 
response message back to the information monitoring 
network; 

f) means for generating from the information received 
from the monitoring system and fi-om each of the one 
or more notification contact data entries one or more 
interactive event notifications, each in a device-specific 
format corresponding to each of the one or more 
configured communication receiving devices; 

g) means for transmitting said one or more interactive 
event notifications in device-specific formats to each of 
the one or more configured communication receiving 
devices either sequentially or simultaneously according 
to the specified notification contact flow sequence; 

h) means for receiving from each of the one or more 
communication receiving devices, either sequentially 
or simultaneously according to the specified notifica- 
tion contact flow sequence, additional information or 
instructions containing specified subsequent actions to 
be taken by the network; 

i) means for altering the specified notification contact flow 
sequence according to the specified subsequent actions 
contained in the additional information or instructions 
received from each of the one or more configured 
communication receiving devices; and 

j) means for carrying out subsequent actions to be taken 
by the network according to the altered specified noti- 
fication contact flow sequence. 

2, The information management network system of claim 
1 wherein the monitoring system is a premises monitoring 
system. 

3. The information management network system of claim 
1 wherein the information received firom a monitoring 
system comprises an alarm or event notification. 
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4. The information management network system of claim 
2 wherein the premises monitoring system is located 
remotely from the network system at a remote premises. 

5. The information management network system of claim 
1 wherein the user is a customer of an entity maintaining the 
information management network system. 

6. Tlie information management network system of claim 
1 additionally comprising a premises monitoring system. 

7. The information management network system of claim 
1 additionally comprising 

a) one or more event logs corresponding to the one or 
more user profiles; and 

b) means for storing in the event log information com- 
prising the information received from the monitoring 
system and information regarding the one or more 
interactive event notifications sent by the network. 

8. The information management network system of claim 
7 additionally comprising means for the user to access and 
retrieve information stored in the event log. 

9. The information management network system of claim 
additionally comprising: 

a) means for enabling a user to remotely access the user's 
user profile and the corresponding event log; and 

b) means for enabling the user, after having accessed the 
user's profile, to change the specified notification con- 
tact data entries and the specified notification contact 
flow sequence, thereby changing the order and manner 
in which event notifications are transmitted to the one 
or more configured communication receiving devices. 

10. The information management network system of 
claim 9 wherein the means for enabling a user to remotely 
access the user's user profile and the corresponding event 
log is either a telephone interface or an internet interface, 

11. The information management network system of 
claim 1 in which the one or more configxired communication 
receiving devices to which interactive event notifications arc 
directed are selected from the group: cell phone, e-mail, 
pager, land line phone, text messaging device, short mes- 
saging system, facsimile machine, and all combinations 
thereof. 

12. The information management network system of 
claim 1 in which at least one of the one or more configured 
communication receiving devices is located at a staffed 
central station, and in which the device-specific format is a 
security industry data format, whereby the staffed central 
station is enabled to notify emergency authorities of the 
information received from the monitoring system. 

13. The information management network system of 
claim 12 ia which the staffed central station is enabled to 
send notification of an event to the user's home and to route 
a notification to the user at another location either concur- 
rently with the notification to the home or sequentially. 

14. The information management network system of 
claim 1 additionally comprising a means for voice telephone 
conferencing. 

15. The information management network system of 
claim 1 additionally comprising means for sending out 
messages to users reminding them to update their user 
profiles. 

16. The information management network system of 
claim 15 wherein the means for sending out messages to 
users comprises via email providing a link whereby to the 
web site for users can update their user profiles, 

17. The information management network system of 
claim 15 wherein the means for sending out messages to 
users comprises a telephone interface, whereby the user is 
enabled to use the telephone key pad to update the user's 
user profile. 
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18. A method of routing information to one or more 
recipients comprising the steps of: 

a) receiving information from a monitoring system; 

b) storing one or more tiser profiles, each of the one or 
more user profiles comprising one or more specified ^ 
notification contact data entries and a specified notifi- 
cation contact flow sequence; 

c) selecting a single user profile corresponding lo the 
monitoring system 

d) retrieving the selected single user profile; 

e) extracting from the selected single user profile the one 
or more specified notification contact data entries and 
the specified notification contact flow sequence; 

f) identifying from each of the one or more notification 
contact data entries one or more communication receiv- 
ing devices and for each such device a device-specific 
format, each of said communication receiving devices 
being configured both to receive messages in device- 
specific formats and to transmit a response message 20 
back to the information monitoring network; 

g) generating from the information received from the 
monitoring system and from each of the one or more 
notification contact data entries one or more interactive 
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event notifications^ each in a device-specific format 
corresponding to each of the one or more configured 
communication receiving devices; 

h) transmitting said one or more interactive event notifi- 
cations in device-specific formats to each of the one or 
more configured communication receiving devices 
either sequentially or simultaneously according to the 
specified notification contact flow sequence; 

i) receiving from each of the one or more communication 
receiving devices, either sequentially or simultaneously 
according to the specified notification contact flow 
sequence, additional information or instructions con- 
taining specified subsequent actions to be taken by the 
network; 

j) altering the specified notification contact flow sequence 
according to the specified subsequent actions contained 
in the additional information or instructions received 
from each of the one or more configured communica- 
tion receiving devices; and 
carrying out subsequent actions to be taken by the network 
according to the altered specified notification contact flow 
sequence. 
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